CVE-2024-42313

What it actually does

Use-after-free in the Linux kernel venus vdec_close path allows the firmware to queue buffer release work via HFI callbacks; closing the decoder device from userspace during active decoding results in a read-after-free on the inst structure.

Why it matters to the business

Local attackers on affected Linux systems can trigger crashes, memory corruption, or full system compromise; the flaw affects video decoding workloads on devices using the venus driver and has been present for over two years without broad exploitation.

How an attack unfolds

An attacker with local access opens a venus decoder instance, begins normal decoding so firmware schedules work items, then abruptly closes the device from userspace; the pending work later dereferences the freed inst object, enabling read primitives that can be turned into arbitrary code execution or information leaks.

How to fix it

Update the Linux kernel to commit ad8cf035baf29467158e0550c7a42b7bb43d1db6 or later; AlmaLinux 8 users should install libvpx-1.7.0-11.el8_10 and libvpx-devel-1.7.0-11.el8_10 packages; rebuild and reboot with the patched kernel, and verify the venus driver is no longer vulnerable by checking the fixed commit is present.

How to confirm the fix worked

Confirm the running kernel contains commit ad8cf035baf29467158e0550c7a42b7bb43d1db6; on AlmaLinux 8 verify package versions are at least 1.7.0-11.el8_10; attempt to reproduce the original close-during-decode scenario under a debugger to ensure no use-after-free occurs.

Typical attack path

1. Obtain local user access on a vulnerable Linux system using the venus media driver
2. Open a video decoder device and initiate decoding to trigger firmware HFI callbacks
3. Close the decoder device while firmware work items remain queued
4. Trigger the work queue to perform the use-after-free read on the freed inst structure
5. Leverage the resulting memory corruption for privilege escalation or data exfiltration

How to detect it

Review kernel logs for use-after-free warnings or oops involving venus/vdec_close or HFI work items; inspect audit logs for unusual decoder device open/close sequences from non-standard processes; correlate with any local privilege-escalation attempts shortly after decoder activity.

What your security team should do

• Prioritize kernel updates on all systems exposing video decoding via the venus driver
• Restrict untrusted local access and decoder device permissions until patches are applied
• Monitor for new EPSS increases or confirmed exploit code despite current low scores
• Test the fixed kernel in staging environments before broad deployment