search

FDOS / kernel

FreeDOS kernel - implements the core MS-DOS/PC-DOS (R) compatible operating system. It is derived from Pat Villani's DOS-C kernel and released under the GPL v2 or later. Please see http://www.freedos.org/ for more details about the FreeDOS (TM) Project.
http://kernel.fdos.org/
GNU General Public License v2.0
811 stars 144 forks source link

truename: fix array overrun (pick from fdpp) #113

Closed ecm-pushbx closed 1 year ago

ecm-pushbx commented 1 year ago

Picked from the commit at https://github.com/dosemu2/fdpp/commit/fe1c4dc7fe5a2218d3badf90c3a8e43550da5821

The referenced issue is at https://github.com/dosemu2/fdpp/issues/212

The patch was applied using unix2dos on the patch file then patch -p1 --binary with the patch file as stdin. The original used a new define for the maximum path length. As there is no difference to our current SFTMAX define I changed this hunk to retain the SFTMAX use.

This fixes a bug when eg function 3Dh receives a buffer that starts with ".\" but the byte in memory before this buffer happens to be also a dot. I ran into this problem semi-randomly during building EDR-DOS with the most recent WarpLink build. If WarpLink was placed somewhat low in the Low Memory Area then one of its function 3Dh calls would happen to have a dot before the pathname buffer. (I had to load lCDebug using the last fit strategy then enter TSR mode, to catch the bug without the presence of the debugger working around the occurrence of the bug.)

Original commit Metadata:

From: Stas Sergeev stsp@users.sourceforge.net Date: Wed, 1 Feb 2023 13:01:55 +0500 Subject: [PATCH] truename: fix array overrun [fixes #212]

src[-2] was peeking into a random memory location. It seems entire truename() is written by some morons... :( Its completely unreadable and full of bugs.

ecm-pushbx commented 1 year ago

The byte that happened to be before the filename buffer in WarpLink was the high byte of the variable mod_alloc_base which explains that the error only occurred on certain system configurations in which this byte could be 2Eh (the variable being in the range 2E00h to 2EFFh).

The call that happened to exhibit this bug was in EDR-DOS's command/make.bat where the object files are specified to the linker with a path of .\BIN\: https://hg.pushbx.org/ecm/edrdos/file/b390f7f10fd0/command/make.bat#l67