CVE-2026-89724
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux video handling could let a logged-in user damage internal memory structures, potentially crashing the system or gaining higher privileges.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Out-of-bounds write in the FWHT encoder when processing 4-component pixel formats: the capture buffer is sized using sizeimage_mult=3 but an incompressible frame triggers verbatim copies of four full-resolution planes, writing sizeof(struct fwht_cframe_hdr) + 4*coded_w*coded_h bytes and overrunning the buffer by one plane's worth of data, corrupting adjacent kernel heap.
Why it matters to the business
Local users on affected Linux systems can trigger kernel memory corruption, leading to system instability, crashes, or potential elevation of privileges on media-processing workloads that use the vicodec driver.
How an attack unfolds
An attacker with local access opens the vicodec device, selects a 4-component raw format via VIDIOC_S_FMT, supplies an input frame whose every plane forces the unencoded fallback path in encode_plane(), and causes the oversized write into the undersized capture buffer allocated from the pixfmt_fwht descriptor.
How to fix it
Apply the upstream fix that raises pixfmt_fwht.sizeimage_mult from 3 to 4 in the vicodec driver; rebuild and deploy the updated kernel image. Where immediate patching is not possible, restrict unprivileged access to the video codec device nodes.
How to confirm the fix worked
Inspect the kernel source for the commit that sets sizeimage_mult=4 in pixfmt_fwht, verify the running kernel version contains the change, or confirm that VIDIOC_S_FMT for 4-component formats now allocates capture buffers large enough for the unencoded fallback path.
Typical attack path
- Obtain local shell or user context on the target Linux system
- Open /dev/video* device exposing the vicodec driver
- Issue VIDIOC_S_FMT with a 4-component pixel format that sets width_div=height_div=1
- Submit a frame that forces every plane through the FWHT_FRAME_UNENCODED path
- Trigger kernel heap overwrite and subsequent corruption or exploitation
How to detect it
Search kernel logs (dmesg, /var/log/kern.log) for vicodec or fwht_encode_frame oopses, slab corruption warnings, or general protection faults immediately following VIDIOC_S_FMT calls on video devices; correlate with process activity opening /dev/video* nodes.
What your security team should do
- Prioritize kernel update containing the sizeimage_mult fix on all systems exposing vicodec
- Limit device-node access via udev rules or LSM policies until patched
- Monitor kernel oops/panic logs for vicodec-related buffer-overrun signatures
- Reassess after 30 days if EPSS or exploit maturity increases
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|