Cloudanix VulnDB

CVE-2026-89741

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A mistake in how the Linux kernel cleans up video devices when registration fails can let a local user crash the system or take control.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Error-handling path in __video_register_device allows put_device to free the video_device struct while video_device_release also kfree's the same allocation, producing a classic double-free (use-after-free) on registration failure.

Why it matters to the business

Local users on affected kernels can trigger a kernel crash or escalate privileges during video-device initialization; organizations running media workloads face unplanned reboots, potential data corruption, and the need for emergency kernel updates.

How an attack unfolds

An attacker with local access loads or triggers a V4L2 driver that calls video_register_device, forces the device_register step to fail, and re-uses the now-freed video_device object to corrupt kernel memory and obtain code execution.

How to fix it

Upgrade to a kernel containing the revert commit; if the original flawed patch is present, apply the revert or the corrected two-phase registration model once available. Reboot after update.

How to confirm the fix worked

Confirm the revert commit (or equivalent fix) is present in the running kernel source or binary; attempt controlled video_register_device failure paths in a test environment and verify absence of double-free warnings in kmemleak or KASAN.

Typical attack path

  1. Obtain local shell on target system
  2. Trigger V4L2 device registration that reaches the error path in __video_register_device
  3. Force device_register failure
  4. Reuse freed video_device object for arbitrary kernel read/write
  5. Escalate to root or install persistence

How to detect it

Review kernel logs for double-free or slab-use-after-free warnings around video_device allocations; inspect any crash dumps referencing __video_register_device or video_device_release; correlate with recent V4L2 device load attempts.

What your security team should do

  • Prioritize kernel updates on any system exposing /dev/video* or using V4L2 drivers
  • Harden local access controls and limit untrusted module loading until patched
  • Monitor for future V4L2 registration-model refactor that eliminates the underlying conflict

The record

In the Linux kernel, the following vulnerability has been resolved: Revert "media: v4l2-dev: fix error handling in __video_register_device()" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.

Affected packages

Ecosystem Package Introduced Fixed