CVE-2026-68207

What it actually does

On probe failure after v4l2_device_register succeeds, the driver returns without calling v4l2_device_unregister, leaving a partially registered V4L2 device in the kernel.

Why it matters to the business

Systems may experience driver loading failures or resource leaks during hardware initialization, increasing maintenance overhead and potential downtime on affected Linux kernels.

How an attack unfolds

An attacker with local access or ability to trigger module loading could induce repeated probe failures to accumulate leaked registrations, but the low EPSS and absence of known threat actor usage indicate minimal practical exploitability.

How to fix it

Update to a Linux kernel containing the referenced fix that routes the vpe_top error path through v4l2_device_unregister; rebuild and deploy the updated kernel image.

How to confirm the fix worked

Confirm the presence of the unwind label change in the vpe_probe function within the ti-vpe driver source; test probe error paths to ensure v4l2_device_unregister is invoked on all failure routes after registration.

Typical attack path

1. Trigger repeated load attempts of the ti-vpe driver under conditions where vpe_top resource is absent
2. Observe accumulation of registered v4l2 devices without corresponding cleanup
3. Leverage resulting state for denial-of-service or to interfere with subsequent driver operations

How to detect it

Inspect kernel logs and dmesg output for repeated vpe_probe failures followed by missing unregister calls; examine /sys or /proc entries for orphaned v4l2 device registrations after failed module loads.

What your security team should do

• Prioritize kernel updates on systems using the TI VPE media driver
• Monitor for related driver stability issues during boot or module insertion
• Review kernel logs for v4l2 registration anomalies on affected hardware