CVE-2026-31473

What it actually does

This is a local Linux kernel use-after-free in the media controller / Video4Linux2 request API. A race can occur when MEDIA_REQUEST_IOC_REINIT runs concurrently with VIDIOC_REQBUFS(0), causing request object cleanup to overlap with videobuf2 queue teardown or cancellation. If an attacker with local access can open a request-capable media device and repeatedly trigger the racing ioctl paths, freed kernel memory may be accessed again. Successful exploitation could cause a kernel crash or, with reliable heap manipulation, potentially allow local privilege escalation and arbitrary kernel memory corruption.

Why it matters to the business

Systems exposing request-capable Linux media devices could be vulnerable to local denial of service or privilege escalation by a user or compromised low-privilege process. The CVSS score is high because successful exploitation can affect confidentiality, integrity, and availability at the kernel level, but current urgency is moderated by low EPSS, no known public exploit maturity, no CISA KEV listing, and no known ransomware use. Risk is highest for Linux endpoints, embedded systems, video-processing appliances, developer workstations, kiosks, or servers where untrusted users or workloads can access /dev/media*, /dev/video*, or related V4L2 devices.

How an attack unfolds

An attacker first needs local code execution or an account with permission to access a request-capable Linux media device. They identify accessible media or V4L2 device nodes, open the relevant descriptors, and create conditions where media requests and videobuf2 buffer queues are active. The attacker then repeatedly invokes MEDIA_REQUEST_IOC_REINIT while concurrently invoking VIDIOC_REQBUFS with a count of zero to tear down buffers. Without the kernel-side serialization fix, these paths may run in parallel and cause request cleanup to race against queue cancellation. The immediate result may be a kernel warning, KASAN report, or system crash; a more advanced exploit would try to shape kernel heap state around the freed object to convert the use-after-free into controlled memory corruption and privilege escalation.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for serializing MEDIA_REQUEST_IOC_REINIT and VIDIOC_REQBUFS teardown paths with req_queue_mutex. No exact fixed package versions were provided, so use vendor advisories for the deployed kernel stream and update to the first patched kernel or later. Where immediate patching is not possible, reduce exposure by restricting access to media/V4L2 device nodes, removing unnecessary users from video/media-related groups, disabling or unloading unneeded media device drivers, blocking passthrough of camera/video devices into containers or virtual machines where not required, and enforcing least-privilege device cgroup rules for workloads.

How to confirm the fix worked

Confirm that deployed kernels include the vendor backport or upstream change that serializes REINIT and REQBUFS using req_queue_mutex. Validate by checking installed kernel package changelogs, vendor security advisories, or source patches for changes in media_request_ioctl_reinit and REQBUFS/vb2 queue teardown locking. Inventory systems for accessible /dev/media*, /dev/video*, /dev/v4l-subdev*, and related device nodes, and verify permissions are limited to trusted users and services. After patching, reboot into the updated kernel and confirm with uname -a and package manager output that the running kernel matches the fixed package. In test environments, race reproducers or media ioctl stress tests should no longer produce KASAN use-after-free reports, kernel warnings, oopses, or panics in the affected media/vb2 paths.

Typical attack path

1. Gain local code execution as an unprivileged user or compromise a low-privilege process on a Linux system.
2. Check for accessible request-capable media/V4L2 device nodes such as /dev/media* or /dev/video*.
3. Open the media device and prepare request/buffer state using media controller and V4L2 ioctls.
4. Run concurrent threads or processes that call MEDIA_REQUEST_IOC_REINIT and VIDIOC_REQBUFS with zero buffers.
5. Trigger the race so request object cleanup overlaps with videobuf2 queue cancellation.
6. Cause a kernel crash or attempt heap grooming to turn the use-after-free into kernel memory corruption.
7. If exploitation is reliable, escalate privileges or disable the system through kernel panic or instability.

How to detect it

Look for evidence of attempted exploitation in kernel and audit telemetry rather than network logs, because exploitation is local. Relevant sources include dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, pstore/ramoops, kdump/vmcore records, auditd syscall/device-access logs, EDR process telemetry, and container runtime device passthrough logs. Investigate kernel messages showing use-after-free, KASAN, slab corruption, refcount errors, kernel BUG/WARNING, oops, panic, or general protection faults that reference media request handling, videobuf2, v4l2, vb2, REQBUFS, or REINIT. Correlate those events with local processes opening /dev/media*, /dev/video*, or /dev/v4l-subdev* and issuing rapid or concurrent ioctl activity. Repeated crashes involving the same media stack paths, especially initiated by non-interactive users, containers, test binaries, or unexpected processes, should be treated as suspicious. There are no known public exploit-specific file names, malware names, command lines, or network indicators for this issue based on the provided data.

• MEDIA_REQUEST_IOC_REINIT
• VIDIOC_REQBUFS
• media_request_ioctl_reinit
• req_queue_mutex
• vb2_core_reqbufs
• videobuf2
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• kernel oops
• /dev/media
• /dev/video
• /dev/v4l-subdev

What your security team should do

• Prioritize patching Linux systems where untrusted users, shared workloads, containers, desktop users, or exposed media devices can access V4L2/media device nodes.
• Inventory systems with /dev/media*, /dev/video*, and request-capable media devices; treat multi-user systems and container hosts with device passthrough as higher risk.
• Restrict device node permissions and remove unnecessary membership in video, media, render, or equivalent hardware-access groups.
• Do not pass camera, capture, or media devices into containers, sandboxes, CI jobs, or virtual machines unless explicitly required.
• Monitor kernel logs for use-after-free, KASAN, kernel oops, BUG, WARNING, or panic messages referencing media_request_ioctl_reinit, MEDIA_REQUEST_IOC_REINIT, VIDIOC_REQBUFS, vb2, or videobuf2.
• Review EDR or audit telemetry for unusual local programs repeatedly opening /dev/media* or /dev/video* and issuing high volumes of ioctls.
• Because there is no known public exploit or KEV listing, handle as a high-impact local kernel flaw rather than an internet-facing emergency, unless local untrusted access is common in the environment.