Look up another CVE · open CVE-2026-68228 in the interactive tracker
CVE-2026-68228
media: chips-media: wave5: Move src_buf Removal to finish_encode
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem drivers/media. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-68228 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
- What this is
- WAVE5 VPU CODEC DRIVERMAINTAINERS section matched on drivers/media/platform/chips-media/wave5/ · linux-media@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_VIDEO_WAVE_VPU /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 4 releases. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixie, forky, sid, bookworm · linux-6.12n
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_VIDEO_WAVE_VPU
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/media
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.8 | 6.12.101 | 1ee2b2b189dd |
| 6.8 | 6.18.42 | f24ca8b53fe1 |
| 6.8 | 7.1.6 | d681227ce43b |
| 6.8 | 7.2 | b20157147089 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is reached only through V4L2 ioctls (REQBUFS/QBUF/DQBUF/STREAMON) on the local Wave5 encoder device node /dev/videoX; no network or remote input path exists.
- AC:LAttack complexity, low
- Although a race, the attacker controls both sides: it drives the QBUF timing against the encode-completion IRQ and can retry on every encoded frame in a tight loop until the window is hit, so triggering is reliable.
- PR:LPrivileges required, low
- An unprivileged local process that can open the encoder video node (normal on Android/embedded TI platforms where media apps hold access, or any user in the video group) can drive the full encode sequence; no capabilities are checked.
- UI:NUser interaction, none
- The attacking process performs all encode setup and buffer queueing itself; no action by another user or victim is needed.
- S:UScope, unchanged
- Corruption is confined to kernel memory managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- The m2m ready-queue list corruption plus a vb2 buffer simultaneously owned by userspace and the driver yields dangling/poisoned kernel pointers and buffer state confusion that can be leveraged to read kernel memory contents.
- I:HIntegrity impact, high
- Doubly-linked list corruption gives an attacker-influenced write through list_add/list_del on a self-looped node, and a freed-then-reused buffer object, both of which are classic primitives for controlled kernel memory modification.
- A:HAvailability impact, high
- The self-loop and subsequent __list_del leave the ready queue head detached with poisoned pointers, causing LIST_POISON dereference oops, unterminated list traversal, or a use-after-free crash that takes down the kernel.