CVE-2026-68223
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A programming mistake in a video decoder driver could let memory slowly leak away on certain devices until the system becomes unstable or crashes.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Other
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Memory leak of m2m context object in vdec_open error path when vdec_init_ctrls fails, because the function jumps to an incorrect label that bypasses v4l2_m2m_ctx_release.
Why it matters to the business
Repeated triggering of the error path on affected meson video decoder devices can exhaust kernel memory, leading to performance degradation, instability, or eventual denial of service on embedded or multimedia Linux systems.
How an attack unfolds
An attacker with local access opens the meson vdec device node, forces vdec_init_ctrls to fail, and repeats the operation; each failure leaks an 8-byte m2m context object without releasing the associated resources, gradually depleting memory.
How to fix it
Apply the upstream fix that adds an err_m2m_ctx_release label calling v4l2_m2m_ctx_release before m2m device release; rebuild and deploy updated kernel images containing the corrected vdec_open logic.
How to confirm the fix worked
Verify the patch is present by inspecting the vdec_open function for the err_m2m_ctx_release label and v4l2_m2m_ctx_release call; run kmemleak after repeated open/close cycles that hit the error path and confirm no new unreferenced objects appear.
Typical attack path
- Obtain local shell or process on target system
- Open /dev/video* or equivalent meson vdec device
- Trigger vdec_open such that vdec_init_ctrls returns failure
- Repeat to accumulate unreleased m2m_ctx allocations
- Observe memory pressure or kmemleak reports
How to detect it
Inspect kmemleak reports for allocations originating from vdec_open and v4l2_ctrl_handler_init_class; review audit logs for repeated open attempts on meson video devices that coincide with increasing memory usage.
What your security team should do
- Prioritize kernel update on all systems exposing meson vdec devices
- Enable kmemleak or similar leak detectors in test and production kernels
- Restrict unprivileged access to video decoder device nodes via udev or permissions
- Monitor memory usage trends on affected hardware platforms
The record
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm "v4l_id", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|