[no subject]

So, as a workaround for v2.0.0 users we can just tell them to use shorter
filenames. Max length still to be determined (unicode encoding related? 16
bit chars?).

/Troed

On Fri, Nov 25, 2016 at 10:34 PM, Christian Zietz <czietz@xxxxxxx> wrote:

> David Savinkoff schrieb:
>
> > "Abort trap 6" is searchable on the internet.
>
> "Abort trap 6" seems to point to a bug regarding memory corruption etc.
>
> Recall that Hatari crashes directly after the message "Mounting hard
> drive image ...". I see a *confirmed* buffer overflow in
> HDC_CheckAndGetSize, which a) is called directly after that message b)
> was introduced inbetween Hatari 1.9.0 and 2.0.0.
>
> HDC_CheckAndGetSize calls ...
>
> File_ShrinkName(shortname, filename, sizeof(shortname));
>
> ... however, as you can easily check, File_ShrinkName will reduce long
> filenames to a maximal *string* length equal to its last parameter. The
> final \0 byte will take another byte in that buffer. So the 'shortname'
> buffer overflows for long filenames.
>
> From the original crash report on atari-forum.com, you can see that
> indeed the filename of the HD image is longer than 48
> (=sizeof(shortname)), so this buffer overflow happens there.
>
> Now I haven't checked how File_ShrinkName is called elsewhere, but you
> should either fix CheckAndGetSize or File_ShrinkName so that this buffer
> doesn't overflow. Maybe this will already fix the crashes on MacOS. (It
> seems that Windows and Linux are perhaps a little less sensitive to an
> overflow by one byte?)
>
> Regards
> Christian
> --
> Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
> WWW: http://www.chzsoft.de/
> PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
>
>
>

--001a114d7fae2802ac054227d3bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>From your mail I would assume it would be enough to u=
se images with &lt;48 char filenames. However, the image I tested is named =
&quot;400MB_image_easymint_68k_ext2.img&quot; which is a lot less than 48. =
However, after renaming it to &quot;400MB.img&quot; it indeed booted just f=
ine.</div><div><br></div><div>So, as a workaround for v2.0.0 users we can j=
ust tell them to use shorter filenames. Max length still to be determined (=
unicode encoding related? 16 bit chars?).</div><div><br></div><div>/Troed</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri,=
 Nov 25, 2016 at 10:34 PM, Christian Zietz <span dir=3D"ltr">&lt;<a href=3D=
"mailto:czietz@xxxxxxx"; target=3D"_blank">czietz@xxxxxxx</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">David Savinkoff schrieb:<br>
<span class=3D""><br>
&gt; &quot;Abort trap 6&quot; is searchable on the internet.<br>
<br>
</span>&quot;Abort trap 6&quot; seems to point to a bug regarding memory co=
rruption etc.<br>
<br>
Recall that Hatari crashes directly after the message &quot;Mounting hard<b=
r>
drive image ...&quot;. I see a *confirmed* buffer overflow in<br>
HDC_CheckAndGetSize, which a) is called directly after that message b)<br>
was introduced inbetween Hatari 1.9.0 and 2.0.0.<br>
<br>
HDC_CheckAndGetSize calls ...<br>
<br>
File_ShrinkName(shortname, filename, sizeof(shortname));<br>
<br>
.... however, as you can easily check, File_ShrinkName will reduce long<br>
filenames to a maximal *string* length equal to its last parameter. The<br>
final \0 byte will take another byte in that buffer. So the &#39;shortname&=
#39;<br>
buffer overflows for long filenames.<br>
<br>