CVE-2026-68228

What it actually does

Race condition in wave5 encoder buffer handling allows a v4l2 buffer to be marked DONE and returned to userspace while still present in the m2m ready queue; subsequent queueing of the same buffer creates a self-referential list entry via WRITE_ONCE in __list_add, so that __list_del later poisons pointers without restoring the list head.

Why it matters to the business

Local users can trigger kernel memory corruption leading to denial of service or privilege escalation on systems using the wave5 video codec driver, potentially affecting media-processing workloads and embedded Linux devices.

How an attack unfolds

An attacker with local access crafts a sequence of V4L2 buffer queue and encode operations that races the IRQ completion path against start_encode, causing the buffer to re-enter the ready queue before removal; when finish_encode eventually calls __list_del the list is already looped, resulting in corrupted list state that can be leveraged for further memory manipulation.

How to fix it

Update to a kernel containing the fix that moves src_buf removal entirely into finish_encode before any v4l2_m2m_buf_done call; rebuild and deploy the media subsystem modules or full kernel image as appropriate for the distribution.

How to confirm the fix worked

Confirm the patch is present by inspecting the wave5 driver source for the moved list removal logic in finish_encode; run V4L2 encoder stress tests that previously triggered the race to verify absence of list corruption; monitor kernel logs for related warnings during buffer processing.

Typical attack path

1. Obtain local shell on affected system
2. Open V4L2 encoder device and allocate buffers
3. Rapidly queue the same buffer while encode IRQ fires
4. Trigger the window where v4l2_m2m_buf_done returns buffer before removal from ready queue
5. Force list corruption via subsequent __list_del on poisoned entry
6. Exploit resulting memory state for escalation or crash

How to detect it

Review kernel logs for list corruption warnings or oopses involving __list_del and wave5; inspect V4L2 application traces for repeated buffer reuse patterns that coincide with IRQ completion; correlate with process activity on video encoder devices.

What your security team should do

• Prioritize kernel update on any system exposing the wave5 encoder to untrusted local users
• Restrict access to /dev/video* nodes via device ACLs until patched
• Monitor for unusual V4L2 buffer handling errors in dmesg after deployment
• Rebuild custom kernels with the corrected wave5.c if using out-of-tree media drivers