Summary

bmp_Init validates only that width/height/ncols fit the screen (line 540) but NEVER validates that the declared pixel array (bfOffBits + width*height*bpp/8) fits inside bmp_decoder.data_size. info->data is set from the attacker- controlled bfOffBits field (line 516) and every subsequent decoder fetch (RLE encoded/absolute modes and the BI_RGB row loops) advances and dereferences info->index with zero bounds checks. A crafted splash BMP makes the kernel read arbitrary-amount / arbitrary-offset kernel memory; the bytes are painted into the VGA framebuffer which is readable back through /dev/fb*, yielding a kernel memory info leak, and a malformed RLE stream that never emits an end-of-bitmap escape reads forward until it hits an unmapped page and panics (DoS).

Root cause

bmp_start only checks bmp_decoder.data_size <= 0 (line 80) — never that the file is large enough for even the BITMAPF header (1078 bytes), let alone the pixel array. In bmp_Init:

bmp_info.data = (const u_char *)data + bmf->bmfh.bfOffBits;   /* line 516 */

bfOffBits is a signed int read straight from the attacker file, added to data with NO check that 0 <= bfOffBits and NO check that bfOffBits + pixel_bytes <= data_size. width/height/depth come from the header unchecked for size (lines 519-521); only screen-fit is checked (540-547).

bmp_Draw sets bmp_info.index = bmp_info.data; (line 585) and the outer loop (610) only terminates when index becomes NULL (end-of-bitmap RLE escape). There is no check that index stays in [data, data+data_size).

Fetches with no bounds: - RLE encoded run *info->index / *(info->index+1) then index += 2 (lines 323-331, 387-390) - RLE absolute mode *(info->index + 2 + count) for attacker-chosen count (lines 350-351, 409-410) - RLE delta *(info->index+2)/(+3) (345-346, 404-405) - BI_RGB 8bpp row *info->index loop + index += 3 - (--x%4) padding (436-438) - BI_RGB 4bpp ((x+7)/8)*4 advance (452) - BI_RGB 1bpp ((x+31)/32)*4 advance (467)

data_size is computed correctly by splash.c:71 but is never consulted by this file.

Threat model & preconditions

• Attacker position: anyone who can write the boot splash image file or the boot configuration that loads it as the splash_image_data preloaded module (splash.c:33,61). On multi-user systems where /boot or the ESP is writable by a non-root service account, or on kiosk/embedded DragonFlyBSD appliances where the splash asset is operator-writable, this crosses a trust boundary.
• Privileges gained or impact:
• Kernel memory disclosure — set bfOffBits to point at a known kernel text/data region, or declare dimensions larger than the file. The renderer copies that memory into the framebuffer; any process with read access to /dev/fb0 recovers the bytes.
• Reliable local DoS — a tiny malformed RLE BMP (or any BI_RGB BMP whose declared dimensions exceed the real file) walks info->index into an unmapped page and panics the kernel during early boot / first console switch.
• Required config or capabilities: splash_bmp_load=YES in loader.conf; write access to the splash image asset; /dev/fb* read access for the leak path.
• Reachability: boot with the crafted splash image, or trigger console redraw.

Proof of concept

PoC source: findings/poc/DF-1857/mkbmp.c

Build & run

cc -o mkbmp mkbmp.c
./mkbmp bad.bmp
# Install as splash asset, add splash_bmp_load=YES to loader.conf, reboot.
# After boot, read the framebuffer:
dd if=/dev/fb0 of=leaked.bin bs=64000 count=1
# leaked.bin contains raw kernel memory painted by the BMP decoder

Expected output

# Info leak:
# leaked.bin contains non-palette kernel bytes (pointers, text) correlated
# with `nm /boot/kernel/kernel`

# DoS variant (RLE without end-of-bitmap escape):
Fatal trap 12: page fault while in kernel mode
...
bmp_DecodeRLE8+0x.. at 0x..

Impact

High-severity kernel-memory info leak + DoS. The leak path crosses a privilege boundary: root installs the crafted splash, unprivileged users read the leaked kernel memory via /dev/fb0. The DoS path panics during boot.

Recommended fix

Validate in bmp_Init that (a) the whole declared pixel array lies within data_size, (b) bfOffBits is sane, (c) depth is in {1,4,8}. Pass data_size into BMP_INFO so every decoder fetch can bounds-check index.

See the finding's fix diff in the full markdown (adds data_end field, validates bfOffBits + pixel_array_size <= data_size for BI_RGB, validates depth in {1,4,8}, and threads data_size through from bmp_start).

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).