CVE-2026-43189

What it actually does

This is a local Linux kernel denial-of-service flaw in the V4L2 asynchronous media-device binding path. During error handling after an async connection matches a firmware node, the kernel can remove the same async-connection list entry more than once and can dereference the connection's sub-device pointer before it has been initialized. When the vulnerable error path is reached, the result can be a kernel oops, NULL pointer dereference, list-corruption warning, or panic, disrupting system availability. The issue is local-only, requires low-privileged local access, and does not directly provide confidentiality or integrity impact based on the supplied CVSS vector.

Why it matters to the business

Systems that use Linux media, camera, capture, or V4L2-related drivers may be vulnerable to local crashes if an attacker or faulty local workload can trigger the affected device-binding path. The operational impact is service interruption, possible node reboot, loss of video/camera workloads, and instability on endpoints, embedded Linux systems, kiosks, appliances, or servers with media hardware. The EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad exploitation pressure appears low; however, organizations with multi-user Linux systems or exposed local device access should still patch during the next appropriate kernel maintenance window.

How an attack unfolds

An attacker first needs local code execution or an interactive local account on a vulnerable Linux system. They then identify whether the host exposes V4L2/media devices or loads affected media drivers, such as devices under /dev/video*, /dev/media*, or /dev/v4l-subdev*. The attacker attempts to trigger the V4L2 async connection matching and binding sequence in a way that causes a failure after a firmware-node match but before the sub-notifier handling completes. On vulnerable kernels, the cleanup path may unbind and remove an async connection incorrectly or dereference the async connection's uninitialized sub-device pointer. If successful, the kernel emits an oops or panic and the system may hang, reboot, or lose media-subsystem functionality. There is no indication from the supplied data that this vulnerability is remotely exploitable or that it is currently used by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update from the operating-system or appliance vendor that includes the upstream fix for the V4L2 async error-handling issue in drivers/media/v4l2-core/v4l2-async.c. No exact fixed package versions were provided in the input, so use vendor advisories, distribution changelogs, or kernel stable release notes to identify the first fixed build for each supported kernel stream. Where immediate patching is not possible, reduce exposure by restricting untrusted local users from accessing media device nodes, tightening udev permissions for /dev/video*, /dev/media*, and /dev/v4l-subdev*, removing users from video/media-related groups where not required, unloading or blacklisting unused camera/capture/media drivers, and disabling unnecessary physical or virtual media hardware in server and appliance profiles. Because this is a kernel issue, a reboot into the fixed kernel is normally required after updating.

How to confirm the fix worked

Confirm that each affected system is running a vendor kernel build that documents the fix for the V4L2 async connection error-handling bug. Validate with package-manager output, kernel version inventory, and distribution security advisories rather than relying only on the upstream version string, because vendors frequently backport kernel fixes. After patching and rebooting, verify that uname -r matches the intended fixed kernel package and that the old vulnerable kernel is not the active boot entry. For source-based kernels, review drivers/media/v4l2-core/v4l2-async.c to ensure the cleanup path no longer double-removes the async connection and that the async connection's sd field is set before it can be dereferenced during unbind/error handling. Operationally, monitor dmesg or journalctl -k while exercising expected media devices to ensure no new V4L2 async oops, NULL dereference, or list-corruption messages appear.

Typical attack path

1. Obtain local access to a vulnerable Linux system with low privileges.
2. Enumerate loaded media/V4L2 drivers and accessible device nodes such as /dev/video*, /dev/media*, and /dev/v4l-subdev*.
3. Interact with the media subsystem or relevant device stack to reach the V4L2 async matching and binding path.
4. Trigger an error condition after an async connection matches a firmware node but before cleanup completes safely.
5. Cause the vulnerable error-handling path to dereference an unset sub-device pointer or corrupt async-connection list state.
6. Induce a kernel oops, panic, system reboot, or loss of affected media services.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs and crash artifacts rather than network telemetry, because this is a local kernel availability issue with no remote indicator. Check journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore storage, apport or ABRT crash reports, and hypervisor reset events for kernel oops, panic, NULL pointer dereference, or list-corruption events involving the V4L2 async subsystem. Look for stack traces containing v4l2_async_match_notify, v4l2_async_unbind_subdev_one, v4l2_async_nf_try_all_subdevs, or drivers/media/v4l2-core/v4l2-async.c. Correlate crash times with auditd, EDR, shell history, sudo logs, and process execution records showing local interaction with /dev/video*, /dev/media*, /dev/v4l-subdev*, media-ctl, v4l2-ctl, ffmpeg, gstreamer, camera services, or custom media test tools. Repeated crashes on demand, crashes shortly after media device enumeration, or crashes caused by non-administrative users accessing media devices are stronger indicators of intentional triggering. There are no supplied named threat actors, ransomware associations, or network IOCs for this vulnerability.

• v4l2_async_match_notify
• v4l2_async_unbind_subdev_one
• v4l2_async_nf_try_all_subdevs
• drivers/media/v4l2-core/v4l2-async.c
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• list_del corruption
• list_add corruption
• general protection fault
• /dev/video
• /dev/media
• /dev/v4l-subdev
• media-ctl
• v4l2-ctl

What your security team should do

• Inventory Linux systems that expose V4L2/media devices or load media/camera/capture drivers, prioritizing multi-user systems, embedded devices, kiosks, and appliances.
• Patch vulnerable systems with the appropriate vendor kernel update and reboot into the fixed kernel.
• If patching must be delayed, restrict access to /dev/video*, /dev/media*, and /dev/v4l-subdev* to trusted users and services only.
• Remove unnecessary local users from video, media, render, or similar device-access groups where those groups grant media-device access.
• Disable, unload, or blacklist unused media drivers on systems that do not require camera or video-capture functionality.
• Add monitoring for kernel oops, panic, NULL pointer dereference, and V4L2 async stack traces to identify potential exploitation or instability.
• Treat repeated crashes containing v4l2_async_match_notify or v4l2_async_unbind_subdev_one in kernel logs as suspicious, especially when preceded by access to media device nodes by untrusted users.
• Because EPSS is low and the CVE is not in KEV, prioritize based on local-user exposure and operational criticality rather than emergency internet-facing patch procedures.