-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config.c KernelAlloc doesn't check that (UMB) memory is sufficient #203
Comments
The code traced at the end is Lines 367 to 372 in 192cccc
Lines 420 to 422 in 192cccc
I elided the exact crash point but rest assured I did trace it to the KernelAlloc call I linked above. The commands listed are all explained in the prior post, except for |
By the way, the first UMCB is "protected" (my wording) by FreeDOS. Commenting out |
By the way, this also shows the old FreeDOS defect that subsequent UMBs (by the same or other XMS drivers) aren't allocated after the first time that This is the function to allocate UMBs: Line 528 in 192cccc
UmbState which makes it so umb_init only runs successfully once.
lDOS is already better in this regard, it scans for any available UMBs after any device driver was loaded and has three different branches to add a new UMB to the UMCB chain no matter where in the chain it is added: https://hg.pushbx.org/ecm/msdos4/file/eba7d38ff1c6/src/BIOS/init.asm#l3961 |
See also #202 |
Added now: https://hg.pushbx.org/ecm/msdos4/shortlog/584f3d01e25e The default is "Enlarge LMA" but this can be changed by |
I traced a crash that I encountered to the call in
kernel/kernel/config.c
Line 457 in 192cccc
kernel/kernel/config.c
Line 1974 in 192cccc
kernel/kernel/config.c
Line 1924 in 192cccc
The problem is that the latter function never checks that sufficient memory is available in the referenced memory block. In my test case this causes the kernel to overwrite memory not belonging to it, corrupting my little test's int 2Fh handler and likely part of the resident debugger (bootable lDebug) as well.
I'm running in "dosemu2 2.0pre9-dev-20240420-1892-g6a2f4f527 Configured: 2024-04-18 10:57:53 +0000" and booting into a recent lDebug revision. The kernel I use is from the bin/ subdirectory of my most recent build, renamed from kernel.sys to fdkernel.sys, and configured using
sys config fdkernel.sys checkdebugger=1
. I'm also using testpl.com as a device driver, a build of which I uploaded to our server here. (If you really want I can dig up the exact commands to build it from the lDOS boot repo.)The full config file used contains:
The
fred327
alias used in the debugger session is defined as follows:(This adds an override to run a different config file than default.)
The
testumb1.sld
Script for lDebug file used contains:This script reserves 2 KiB at the top of the Low Memory Area (below the resident debugger and possibly EBDA), using the upper 1 KiB for code space and the lower 1 KiB as an improvised "UMB" space. The
v4
variable indicates how much of a gap (in paragraphs) to leave between the top of the LMA and the UMB. I set this to 1 in the test to avoid any possible confounding factors with UMBs that extend the LMA. (This is the original purpose of the test, which showed me that lRxDOS/lMS-DOS incorrectly treat that case.)The code is an int 2Fh handler which offers an XMS entrypoint. The only supported function is function 10h, allocate UMB, and then only the size query (eg with
dx
= 0FFFFh) and exact size allocation are supported. After the UMB is allocated, the int 2Fh handler is changed to chain to its downlink immediately (hiding the XMS entrypoint), and subsequent function 10h calls to the XMS entrypoint say there is no free UMB left.The use of this script is as follows, once booted into lDebug:
The Y command runs a Script for lDebug file, which is read using int 13h when booted into the debugger. The
fred327
alias was listed above. The firstg
command runs up to the debugger check, which had to be enabled usingsys config
as above.r f CY
indicates debugger present to the kernel.The second
g
command runs up to the next breakpoint, which in this FreeDOS kernel test case is theint3
instruction in testpl.com. Therc
command hooks int 2Fh to our handler then. That makes it ready for action, to offer its UMB to the config code after the testpl.com device driver returns. Running a thirdg
command would crash dosemu2, due to the kernel corrupting int 2Fh presumably.I will dump a longer session output as a subsequent comment.
The text was updated successfully, but these errors were encountered: