DF-4422 — draw_pxlcursor_{direct,packed,planar} lack the cursor_base < font_height bound the text path enforces

scvgarndr.c text-mode path validates before use (draw_txtcharcursor:236): if (scp->cursor_base >= h) return; The three pixel-mode cursor draw functions instead use scp->cursor_base unvalidated: draw_pos = VIDEO_MEMORY_POS(scp, at, ...) + (scp->font_height - scp->cursor_base - 1) * line_width; (:789-790, :841-842, :890-891) char_data = &scp->font[... + scp->font_height - scp->cursor_base - 1];

With cursor_base >= font_height (char field, syscons.h:294) both offsets go NEGATIVE: OOB READ before scp->font and OOB WRITE (writel/writeb) that many scanlines ABOVE va_window (before the framebuffer/VGA aperture mapping).

Reachability analysis (why Low/speculative): scp->cursor_base is refreshed from sc->cursor_base via update_cursor_image/sc_set_cursor_image (syscons.c:3183,3205) which clamp only with imax(0, ...) — an upper bound is missing — but sc->cursor_base itself is only ever set at scinit from the BIOS cursor shape (syscons.c:3372: font_height(16) - bios_value.cursor_end - 1, bounded < 16), and no ioctl can set it. A mismatch therefore requires sc->cursor_base >= font_height of a LATER pixel mode with a smaller font (8/14), i.e. BIOS cursor_end <= 7 at boot with a subsequent 8-line pixel mode. QEMU/SeaBIOS reports cursor_end=15 (base 0), so the standard guest cannot trigger it; real firmware varies. CONS_CURSORTYPE (SC_CHAR_CURSOR, scvgarndr.c:221) is reachable unprivileged from the console tty, which is what makes the path live at all.

Verdict: untested (Low severity hardening; trigger is firmware-dependent, not attacker-controlled on this rig). Fix mirrors the text path check.

DF-4422 — draw_pxlcursor_{direct,packed,planar} lack the cursor_base < font_height bound the text path enforces

scvgarndr.c text-mode path validates before use (draw_txtcharcursor:236): if (scp->cursor_base >= h) return; The three pixel-mode cursor draw functions instead use scp->cursor_base unvalidated: draw_pos = VIDEO_MEMORY_POS(scp, at, ...) + (scp->font_height - scp->cursor_base - 1) * line_width; (:789-790, :841-842, :890-891) char_data = &scp->font[... + scp->font_height - scp->cursor_base - 1];

With cursor_base >= font_height (char field, syscons.h:294) both offsets go NEGATIVE: OOB READ before scp->font and OOB WRITE (writel/writeb) that many scanlines ABOVE va_window (before the framebuffer/VGA aperture mapping).

Reachability analysis (why Low/speculative): scp->cursor_base is refreshed from sc->cursor_base via update_cursor_image/sc_set_cursor_image (syscons.c:3183,3205) which clamp only with imax(0, ...) — an upper bound is missing — but sc->cursor_base itself is only ever set at scinit from the BIOS cursor shape (syscons.c:3372: font_height(16) - bios_value.cursor_end - 1, bounded < 16), and no ioctl can set it. A mismatch therefore requires sc->cursor_base >= font_height of a LATER pixel mode with a smaller font (8/14), i.e. BIOS cursor_end <= 7 at boot with a subsequent 8-line pixel mode. QEMU/SeaBIOS reports cursor_end=15 (base 0), so the standard guest cannot trigger it; real firmware varies. CONS_CURSORTYPE (SC_CHAR_CURSOR, scvgarndr.c:221) is reachable unprivileged from the console tty, which is what makes the path live at all.

Verdict: untested (Low severity hardening; trigger is firmware-dependent, not attacker-controlled on this rig). Fix mirrors the text path check.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.