CVE-2026-89724
nicheKernel heap out-of-bounds write in Linux vicodec FWHT encoder
The Linux kernel's vicodec virtual codec driver sizes its encoder CAPTURE buffer for a worst case of 3 full-resolution planes (coded_w * coded_h * 3 plus the FWHT frame header), but when encoding a 4-component pixel format an incompressible frame falls back to copying all four full-resolution planes verbatim into that buffer, writing coded_w * coded_h bytes past its end. A local attacker with access to the vicodec media device node (PR:L, so typically an unprivileged local user on a system where the driver is loaded and the device is accessible) can trigger this by feeding noise-like frames that force every plane down the unencoded path. The result is corruption of adjacent kernel heap memory, which can plausibly yield kernel crashes or privilege escalation to root, reflected in a CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The flaw affects any kernel build that enables the vicodec driver (a test driver under drivers/media/test-drivers) and has the module loaded; mainstream distributions rarely ship it enabled, so real-world exposure is limited. No public proof of concept is known and the issue is not in CISA's KEV catalog.
What to do: Update to a kernel containing the fix that raises pixfmt_fwht.sizeimage_mult from 3 to 4. If the driver is not needed, blacklist the vicodec module or disable CONFIG_VIDEO_VICODEC, and verify it is not loaded (lsmod | grep vicodec) on media test and CI systems. Additionally restrict access to /dev/video* device nodes to trusted users to block unprivileged local triggering.
| Linux kernel, vicodec driver (drivers/media/test-drivers/vicodec, FWHT encoder) | Kernel versions carrying the vulnerable pixfmt_fwht.sizeimage_mult = 3 sizing, prior to the commit bumping sizeimage_mult from 3 to 4; no specific release versi |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.