CVE-2026-31473: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex
In the Linux kernel, the following vulnerability has been resolved:
media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex
MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)
queue teardown paths. This can race request object cleanup against vb2
queue cancellation and lead to use-after-free reports.
We already serialize request queueing against STREAMON/OFF with
req_queue_mutex. Extend that serialization to REQBUFS, and also take
the same mutex in media_request_ioctl_reinit() so REINIT is in the
same exclusion domain.
This keeps request cleanup and queue cancellation from running in
parallel for request-capable devices.
Security readout for executives and security teams
Plain-English summary
A race condition in Linux media-device handling can cause kernel memory to be used after it is freed. A locally authenticated user with access to a request-capable media device could potentially crash the system or compromise confidentiality and integrity. Network-only attackers are not indicated.
Executive priority
Prioritize remediation on multi-user, workstation, kiosk, and media-processing systems exposing V4L2 devices to untrusted accounts. Internet-facing status alone does not create direct exposure. Treat as high priority where local device access exists; otherwise schedule through normal kernel maintenance after confirming applicability.
Technical view
MEDIA_REQUEST_IOC_REINIT can race with VIDIOC_REQBUFS(0) queue teardown, allowing request cleanup and video-buffer cancellation to run concurrently. The resulting use-after-free affects request-capable V4L2 devices. The fix places REINIT and REQBUFS operations within the existing req_queue_mutex exclusion domain.
Likely exposure
Exposure requires a Linux system using affected kernel code, a request-capable media/V4L2 device, local low-privileged access, and permission to interact with that device. The supplied affected-version data is ambiguous, so confirm exposure using kernel commit status and distribution guidance.
Exploitation context
CVSS 3.1 rates this 7.8 with local access, low privileges, low complexity, and no user interaction. The source bundle marks KEV false and provides no evidence of active exploitation or a public exploit. Successful abuse could affect confidentiality, integrity, and availability.
Researcher notes
The flaw is a synchronization failure between request reinitialization and zero-buffer queue teardown. The stated remediation extends req_queue_mutex coverage to REQBUFS and media_request_ioctl_reinit(). The bundle does not identify observed exploitation, affected device drivers, or reliable packaged-version boundaries; avoid inferring them from the supplied version list alone.
Mitigation direction
Install a vendor-supported kernel containing the applicable referenced stable fix.
Check distribution security guidance to map packaged kernel versions to the fixing commit.
Until updated, restrict untrusted local users from accessing affected media devices.
Prioritize shared systems where low-privileged users can access V4L2 hardware.
Validation and detection
Inventory Linux kernel versions and request-capable V4L2 or media devices.
Determine whether the running kernel includes the applicable referenced fix commit.
Review device permissions and group memberships granting untrusted users media-device access.
After updating, verify the fixed kernel is running following any required reboot.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31473 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.