Cloudanix VulnDB

CVE-2026-98915

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small mistake in how a Linux video driver cleans up when it is removed could let a local user crash the system or corrupt memory.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect use of video_unregister_device() instead of vb2_video_unregister_device() during removal of the video-i2c driver leaves the vb2 queue connected after the release handler has been replaced, enabling use-after-free on subsequent file operations.

Why it matters to the business

Linux systems performing video capture or I2C-based media functions risk kernel instability, crashes, or memory corruption that can interrupt critical workloads and require unplanned reboots or driver reloads.

How an attack unfolds

An attacker with local access triggers repeated open/close cycles on the video device while concurrently unloading the driver module; the mismatched unregister leaves dangling vb2 references that are dereferenced after free, resulting in a use-after-free condition.

How to fix it

Apply the upstream kernel commit that replaces video_unregister_device with vb2_video_unregister_device in the video-i2c driver; rebuild and deploy the patched kernel to all affected systems.

How to confirm the fix worked

Confirm the presence of the corrected unregister call in the video-i2c source; verify that loading and removing the module no longer produces use-after-free warnings in kmemleak or KASAN; test with concurrent open/close workloads.

Typical attack path

  1. Obtain local code execution or shell access on the target system
  2. Open the video-i2c device node and keep the file descriptor active
  3. Unload or trigger removal of the video-i2c kernel module
  4. Close the file descriptor to invoke the mismatched release path
  5. Trigger reuse of the freed vb2 queue structures to achieve memory corruption or crash

How to detect it

Search kernel logs and dmesg for video-i2c unload events followed by use-after-free or general-protection faults; inspect ftrace or perf traces for vb2_fop_release calls after module exit; review audit logs for module unload actions by non-root users.

What your security team should do

  • Prioritize kernel updates on systems that load the video-i2c driver
  • Monitor kernel logs for use-after-free reports involving vb2 or video-i2c
  • Restrict unprivileged module loading via kernel lockdown or module signing
  • Schedule driver removal testing in staging environments before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: use vb2_video_unregister_device on driver removal The driver uses vb2_fop_release() as its file release operation, so vb2_video_unregister_device() should be used instead of video_unregister_device() during driver removal. This ensures that the vb2 queue is properly disconnected before the video device is unregistered.

Affected packages

Ecosystem Package Introduced Fixed