Summary

The screen-offset computed in bmp_SetPix, sofs = ((info->height - (y+1) + (info->sheight - info->height)/2) * info->adp->va_line_width), can go NEGATIVE for any y near the bottom of the screen when the image is smaller than the screen, because bmp_SetPix clips y against the SCREEN height (sheight) at line 258, not the IMAGE height (height). The RLE4/RLE8 'delta move' escape (lines 345-346, 404-405) lets a crafted BMP set y to any value in [0, sheight), so a small image (e.g. height=1) centered on a 480-line screen with a delta move of dy=479 yields sofs = (1-480+235)*line_width = a large negative number. The subsequent write *(info->vidmem + sofs) = val (line 295) then writes to memory BELOW va_window.

Root cause

Line 258 clips with y >= info->sheight — screen height, not image height — so y may legally be >> info->height. Line 266 computes the centered base offset using info->height (the image height); when y >= info->height, info->height - (y+1) is negative and, for images much smaller than the screen, outweighs the centering term (info->sheight - info->height)/2, giving a negative sofs.

The RLE decoders expose this directly: bmp_DecodeRLE4/RLE8 implement the BMP 'delta' escape by doing y += *(info->index+3) (lines 346, 405) with an attacker-controlled byte and then call bmp_SetPix(info, x, y, ...) with that y. Even without RLE, the clip at 258 being against sheight instead of height is itself the defect: image rows should never be addressable outside [0, height).

Then at line 295 *(info->vidmem+sofs) = val (8bpp mode) and at line 284 *(info->vidmem + sofs) ^= 0xff (planar mode) write at the unchecked (possibly negative) offset.

For standard VGA modes set_win_org is a no-op (vga.c:1571) so nothing clamps the offset.

Threat model & preconditions

• Attacker position: anyone who can write the boot splash image file.
• Privileges gained or impact: writes attacker-chosen byte values to kernel virtual memory at va_window + negative_offset. Depending on kmem layout this can corrupt adjacent kernel structures or pmap entries backing the aperture, causing memory corruption / kernel panic. Potential local privilege escalation if a useful kernel object happens to precede va_window in KVM.
• Required config or capabilities: splash_bmp_load=YES; write access to splash asset.
• Reachability: boot with crafted RLE BMP containing a delta-move escape.

Proof of concept

Craft an 8-bpp RLE8 BMP: - Image declared width=1, height=1 (fits screen trivially) - Body: 00 02 00 C7 = delta move escape with dx=0, dy=199 → y = 0+199 = 199 < sheight(200) passes clip at 258 - Then 01 5A = run of 1 pixel value 0x5A - bmp_SetPix(info, x=0, y=199, 0x5A) - sofs = (1 - 200 + (200-1)/2) * line_width = (1-200+99)*320 = (-100)*320 = -32000 - *(info->vidmem + (-32000)) = 0x5A — writes below va_window

Expected output

Fatal trap 12: page fault in VGA framebuffer write path
OR memory corruption near va_window in adjacent kernel mappings

Impact

Medium-severity OOB write below va_window. Same attacker as DF-1857 (write access to splash asset). Reliable local DoS; potential privilege escalation with kmem layout control.

Recommended fix

Clip y against the IMAGE height (info->height), not the screen height, and reject negative sofs.

--- a/sys/dev/video/fb/bmp/splash_bmp.c
+++ b/sys/dev/video/fb/bmp/splash_bmp.c
@@ -255,7 +255,8 @@ bmp_SetPix(BMP_INFO *info, int x, int y, u_char val)
     int        newbank;

     /*
      * range check to avoid explosions
      */
-    if ((x < 0) || (x >= info->swidth) || (y < 0) || (y >= info->sheight))
+    /* y is an image row; it must be within the image, which we already
+     * guaranteed fits inside the screen in bmp_Init. */
+    if ((x < 0) || (x >= info->width) || (y < 0) || (y >= info->height))
    return;

     lwkt_gettoken(&vga_token);
@@ -272,6 +273,11 @@ bmp_SetPix(BMP_INFO *info, int x, int y, u_char val)
        * info->adp->va_line_width);
     x += (info->swidth - info->width) / 2;

+    if (sofs < 0) {        /* defensive: never write below the window */
+   lwkt_reltoken(&vga_token);
+   return;
+    }
+
     switch(info->sdepth) {

Timeline

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