UB shift 1<<biBitCount in splash_bmp ncols computation (folded into DF-1857 fix)

Summary

At line 538, bmp_info.ncols = 1 << bmf->bmfi.bmiHeader.biBitCount; performs a left shift of a signed int by an attacker-controlled count. For biBitCount >= 32 (or negative), this is undefined behavior in C.

Root cause

biBitCount (short, line 191) is taken directly from the attacker file (line 521 sets depth from it, but line 538 uses the raw header field). 1 << biBitCount with biBitCount in [9,31] yields 512..2^31 which is then caught by ncols > (1<<sdepth) (sdepth<=8 → 256), so those are rejected. biBitCount >= 32 is UB; biBitCount < 0 is also UB-ish and would make ncols a small/garbage value but the loop at 550 then doesn't execute meaningfully.

Threat model & preconditions

Same as DF-1857: control of the boot splash asset. No demonstrated memory unsafety beyond theoretical UB.

Recommended fix

Fixed for free by DF-1857's proposed depth-validation block (if (depth != 1 && depth != 4 && depth != 8) return 1;) which rejects bad shifts before line 538 is reached.

Timeline

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