CVE-2026-43316

What it actually does

This is a local availability vulnerability in the Linux kernel solo6x10 media driver. The flaw is caused by insufficient bounds checking of a chip_id value before it is used in bit-shift logic associated with TW286x chip detection. Under certain compiler and kernel configuration conditions, particularly with Clang and CONFIG_UBSAN_SHIFT instrumentation, an out-of-bounds chip_id can trigger undefined behavior or cause the compiler to optimize away subsequent logic incorrectly. The practical security impact is denial of service: a local user with access to the affected media device path or driver interface may be able to trigger a kernel warning, driver malfunction, kernel oops, or system crash. The issue does not directly provide confidentiality or integrity impact based on the available information.

Why it matters to the business

Systems using Linux kernels with the affected solo6x10 media driver may be vulnerable to local crashes or service disruption if an untrusted or compromised local user can interact with the relevant video capture hardware or device nodes. The risk is most relevant to systems using supported PCI video capture/DVR hardware, embedded video systems, monitoring appliances, or workloads that expose media devices to local users or containers. The vulnerability has a moderate CVSS score, very low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, affected systems that rely on continuous video capture or physical security monitoring could experience operational disruption if the flaw is triggered.

How an attack unfolds

An attacker first needs local access to a Linux system where the vulnerable kernel driver is present and the solo6x10 media device is available. The attacker then identifies exposed video/media device nodes or driver interfaces associated with the solo6x10 hardware. By interacting with the driver in a way that causes an unexpected or out-of-range chip_id to be evaluated, the attacker can reach the vulnerable logic in the TW286x detection path. On vulnerable builds, the unchecked value may result in an invalid shift operation or undefined behavior, potentially leading to a kernel warning, driver failure, oops, panic, or other availability-impacting condition. There is no indication from the provided data that this vulnerability is being exploited in the wild, used by ransomware campaigns, or associated with named threat actors.

How to fix it

Update the Linux kernel to a version that includes the solo6x10 chip_id bounds-checking fix. Because no exact fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. Prioritize systems that load the solo6x10 driver, contain compatible PCI video capture/DVR hardware, or expose media devices to untrusted local users or containers. If immediate patching is not possible, reduce exposure by unloading or blacklisting the solo6x10 driver where it is not required, restricting permissions on video/media device nodes, preventing untrusted users and containers from accessing host media devices, and applying least-privilege controls such as udev rules, cgroup device policies, SELinux/AppArmor confinement, and container device isolation.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for the solo6x10 out-of-bounds chip_id issue. Validate both installed and running kernel versions, because a reboot is normally required after kernel updates. Check whether the solo6x10 module is present or loaded using module inventory tools such as lsmod, modinfo, and distribution package metadata. Review vendor changelogs or kernel source patches for the solo6x10 chip_id bounds check and unsigned shift correction. If the driver is not required, validate that it is blocked from loading and that no solo6x10-related video/media device nodes are exposed. After remediation, monitor system logs for the absence of repeat kernel UBSAN, oops, panic, or solo6x10 driver errors during normal video capture operations.

Typical attack path

1. Gain local user-level access to a Linux system running an affected kernel.
2. Confirm that the solo6x10 media driver or compatible video capture hardware is present and accessible.
3. Locate exposed media or video device interfaces, such as video4linux device nodes, that allow interaction with the driver.
4. Send crafted or abnormal operations through the relevant device interface to influence driver code paths that evaluate chip_id values.
5. Trigger the vulnerable bounds-checking condition in the solo6x10 TW286x detection logic.
6. Cause a kernel warning, driver failure, kernel oops, panic, or system crash, resulting in denial of service.

How to detect it

There are no public, uniquely attributable exploitation indicators for this vulnerability. Detection should focus on evidence of suspicious local interaction with media device nodes followed by solo6x10 driver errors, UBSAN shift warnings, kernel oops messages, kernel panics, unexpected reboots, or repeated crashes on systems using video capture hardware. Useful log sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, auditd device-access logs, EDR telemetry, and container runtime logs showing device passthrough or access to video/media devices. Look for local processes repeatedly opening or issuing ioctls to /dev/video*, /dev/media*, or related V4L2 devices shortly before kernel instability. Because the vulnerability has low EPSS, no KEV listing, and no known exploit maturity, any suspected exploitation should be correlated carefully with hardware presence, driver load state, and crash timing rather than relying on a single log string.

• solo6x10
• is_tw286x
• drivers/media/pci/solo6x10
• UBSAN: shift-out-of-bounds
• shift exponent is too large
• kernel BUG
• Oops:
• Kernel panic
• /dev/video
• /dev/media
• CONFIG_UBSAN_SHIFT

What your security team should do

• Inventory Linux systems for loaded or available solo6x10 media drivers and compatible video capture hardware.
• Patch affected kernels through the appropriate distribution or vendor update channel, then reboot into the fixed kernel.
• Prioritize systems where local users, containers, media-processing workloads, or appliance functions can access video/media device nodes.
• If patching is delayed, unload or blacklist the solo6x10 driver where it is not operationally required.
• Restrict access to /dev/video*, /dev/media*, and related device nodes to trusted service accounts only.
• Review container and virtualization configurations to ensure host media devices are not passed through to untrusted workloads.
• Enable and monitor kernel crash, oops, and UBSAN logging so attempted exploitation or instability is visible.
• Treat unexplained crashes on video capture or DVR systems as potentially security-relevant until driver-level causes are ruled out.