Look up another CVE · open CVE-2026-68229 in the interactive tracker
CVE-2026-68229
media: cedrus: skip invalid H.264 reference list entries
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem drivers/staging. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-68229 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 | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| 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
Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.
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/staging/media/sunxi/cedrus/cedrus_h264.c
- What this is
- ALLWINNER VPU DRIVERMAINTAINERS section matched on drivers/staging/media/sunxi/cedrus/ · linux-media@vger.kernel.org · Maintained
- Kernel module
- sunxi_cedrus
Check it on the machine
grep -wE 'CONFIG_STAGING|CONFIG_VIDEO_SUNXI|CONFIG_VIDEO_SUNXI_CEDRUS' /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.
lsmod | grep -w sunxi_cedrusPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_STAGING, CONFIG_VIDEO_SUNXI, CONFIG_VIDEO_SUNXI_CEDRUS
- Reads as
- all on means the file is compiled; any one off means it is not.
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.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/staging
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10 | 5.10.265 | a6a109771c51 |
| 5.10 | 5.15.216 | 7ff6f728a243 |
| 5.10 | 6.1.183 | 1db34683b0fb |
| 5.10 | 6.6.148 | 2ee8327c85b3 |
| 5.10 | 6.12.101 | 0af8945fcae7 |
| 5.10 | 6.18.42 | 9924cb548ee7 |
| 5.10 | 7.1.6 | e53112c2de88 |
| 5.10 | 7.2 | 10358ea986c3 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| 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 bug is reached only through the local V4L2 interface on the cedrus video device node (/dev/videoN) via VIDIOC_S_EXT_CTRLS plus QBUF/STREAMON ioctls. There is no remote or network-facing path to the stateless H.264 decoder.
- AC:LAttack complexity, low
- The attacker fully and deterministically controls the out-of-range value: ref_pic_list0/1[i].index is a u8 copied verbatim from the control payload with no validation, so any index in 16..255 immediately produces the out-of-bounds dpb[] access on the next decode run. No race, timing, or uncontrollable memory-layout condition is involved.
- PR:LPrivileges required, low
- Only an unprivileged local account with access to the cedrus video device node is needed (typically the 'video' group, or the media/camera service on Android and embedded Allwinner devices). No capability, CAP_SYS_ADMIN, or root check exists anywhere on the path — cedrus_try_ctrl() validates only SPS chroma format and bit depth.
- UI:NUser interaction, none
- The attacking process performs the entire sequence itself — open the device, set the crafted H.264 slice-params control, queue buffers, start streaming. No victim action, file open, or media mount is required.
- S:UScope, unchanged
- The out-of-bounds read stays within the kernel's own memory and security authority; no VM, IOMMU, or sandbox boundary is crossed. This is a standard in-kernel driver memory-safety defect.
- C:HConfidentiality impact, high
- decode->dpb[] holds 16 32-byte entries at the start of a ~560-byte control allocation, so an attacker-chosen index up to 255 reads at offset 8160 — about 7.6 KB of adjacent kernel heap beyond the object. The read flags/reference_ts values are consumed by the ACTIVE test and vb2_find_buffer() timestamp lookup, giving an attacker-steerable oracle over unrelated kernel heap contents.
- I:NIntegrity impact, none
- The defect is purely a read: num_ref is bounded to V4L2_H264_REF_LIST_LEN by v4l2-ctrls-core.c, so the sram_array[CEDRUS_MAX_REF_IDX] stores stay in bounds, and only a legitimately-looked-up buffer position is written to hardware SRAM. No kernel memory is modified out of bounds.
- A:HAvailability impact, high
- Reading several kilobytes past the end of a slab object can walk off the slab page into an unmapped or poisoned region, and trips KASAN/hardening checks, producing a kernel oops. The trigger is trivially repeatable from an unprivileged process, so the crash can be induced at will.