CVE-2026-68106

This is a division-by-zero in AMD's UVD (Unified Video Decoder) driver where width_in_mb and height_in_mb are calculated by right-shifting pixel dimensions by 4 (dividing by 16), with no validation before entering calculation chains that divide by these values. The fix adds a bounds check rejecting any frame where width < 16 or height < 16 before the vulnerable path executes. That validation makes the division unreachable — the correct security fix, not exception handling around a bug that should persist. The CVE is rated HIGH at 7.8 because the division-by-zero triggers a kernel panic — this is a denial-of-service vector, not a stealth privilege escalation. The 'warn_once' added in the final patch iteration is appropriate noise reduction; an IDS monitoring dmesg for repeated exploitation attempts would see silence after first contact, but that doesn't matter here because the bug crashes the kernel on every trigger. You're not hiding an ongoing intrusion — you're preventing log spam from a crash-and-reboot cycle. What matters practically: ensure the input validation from V1 lands in your kernel. The three-patch sequence (validation, refactor, warn_once) may not cherry-pick atomically across all trees — verify your kernel has the bounds check, not just the logging change. The vulnerable division code was walled off but not removed; future refactors touching the decode path could inadvertently restore reachability. This pattern — performance-critical driver code assuming well-formed inputs, with validation grafted on post-hoc — has multi-decade lineage in graphics drivers. Treat this fix as a band-aid on a structural gap, not a completed audit.

Reviewed through automated stages and approved by a human before publication.