CVE-2026-43246

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel tw9906 media I2C driver. During tw9906_probe(), an error path fails to release memory allocated for V4L2 control handling through v4l2_ctrl_handler_init() and v4l2_ctrl_new_std(). If the vulnerable probe path can be triggered repeatedly, kernel memory may be leaked until system memory pressure causes degraded performance, service instability, or a crash. The issue does not provide confidentiality or integrity impact by itself and requires local privileges or local control over device/driver interaction sufficient to trigger the affected driver probe behavior.

Why it matters to the business

Systems using affected Linux kernel builds with the tw9906 media driver enabled may be exposed to local availability disruption. In practical terms, an attacker or malfunctioning local workload could potentially exhaust system resources and cause service outages or host instability. The risk is lower than remotely exploitable issues because exploitation requires local access and a specific driver path, and there is no known public exploit or CISA KEV listing, but availability-sensitive systems should still prioritize kernel updates during normal maintenance cycles.

How an attack unfolds

An attacker first obtains local access to a Linux system with sufficient privileges or device interaction capability to influence loading, binding, or probing of the tw9906 I2C media driver. The attacker then repeatedly causes the driver probe routine to enter the vulnerable error path. Each failed probe attempt can leave allocated V4L2 control-handler memory unreleased. Over time, repeated triggering accumulates unreclaimed kernel memory, increasing memory pressure. If continued, this can degrade performance, disrupt workloads, trigger out-of-memory behavior, or crash the host, resulting in denial of service. There is currently no indication of exploitation in the wild, no known ransomware use, and EPSS is very low, suggesting limited likelihood of broad exploitation.

How to fix it

Update the Linux kernel to a vendor release that includes the fix for the tw9906 driver memory leak. Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or kernel vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the tw9906 driver if it is not required, restricting local shell access, limiting access to device-management functions, and monitoring for repeated driver load/probe failures. Example mitigation options may include preventing the module from loading through modprobe configuration where operationally safe, or removing unused media/I2C hardware support from custom kernel builds.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package corresponds to a vendor-fixed version or contains the upstream patch that calls v4l2_ctrl_handler_free() on the affected tw9906_probe() error path. Check whether the tw9906 module is present or loaded using standard Linux module inventory commands. If the driver is not required and has been disabled, validate that it does not load after reboot and cannot be autoloaded through normal device discovery. Review kernel logs after update or mitigation to ensure repeated tw9906 probe failures are no longer occurring and that memory usage remains stable during relevant device initialization tests.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the tw9906 media I2C driver present or loadable.
2. Identify whether the tw9906 driver can be loaded, rebound, or forced through probe failure conditions.
3. Repeatedly trigger the vulnerable tw9906_probe() error path through driver/device interaction.
4. Cause unreleased kernel allocations to accumulate over repeated failed probe attempts.
5. Exhaust available memory or create severe memory pressure, leading to degraded performance, service failure, out-of-memory events, or host crash.

How to detect it

To determine whether this was already exploited, review Linux kernel logs, system journal entries, audit logs, and endpoint telemetry for repeated tw9906 driver load, bind, unbind, or probe-failure activity followed by increasing memory pressure or out-of-memory events. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, auditd logs for modprobe or sysfs driver bind/unbind operations, and EDR telemetry for repeated module-management commands. Look for patterns where tw9906-related errors recur many times in a short period, especially when correlated with memory exhaustion, OOM killer activity, service crashes, or host reboots. Absence of tw9906 driver activity generally reduces likelihood of exploitation, but does not replace version-based exposure validation.

• tw9906
• tw9906_probe
• v4l2_ctrl_handler_init
• v4l2_ctrl_new_std
• v4l2_ctrl_handler_free
• modprobe tw9906
• rmmod tw9906
• /sys/bus/i2c/drivers/tw9906/bind
• /sys/bus/i2c/drivers/tw9906/unbind
• Out of memory
• oom-killer
• Killed process

What your security team should do

• Inventory Linux systems to determine whether affected kernel versions are in use and whether the tw9906 media I2C driver is present, enabled, or loaded.
• Prioritize patching for systems where local users, containers with device access, untrusted workloads, or media/I2C hardware interactions are allowed.
• Apply vendor-provided kernel updates that include the tw9906_probe() memory leak fix; reboot where required for the patched kernel to take effect.
• If the driver is unnecessary, disable or blacklist tw9906 as a compensating control until the kernel can be updated.
• Restrict local administrative access and access to device-management interfaces that could influence kernel module loading or device probing.
• Monitor kernel logs for repeated tw9906 probe failures, module load/unload activity, out-of-memory events, and unexplained host instability.
• Because EPSS is low, exploit maturity is listed as none, and the issue is not in CISA KEV, handle this through risk-based patch management rather than emergency internet-facing incident response unless local exploitation indicators are observed.