CVE-2026-46235

What it actually does

This is a local denial-of-service flaw in the Linux kernel saa7164 media driver. During PCI device setup, the driver failed to check whether ioremap() successfully mapped BAR0 or BAR2 device memory. If the mapping failed, later code could dereference a NULL pointer or leave partially initialized device state behind, potentially causing a kernel oops, panic, or unstable driver state. The impact is availability only; it does not provide a known path to data disclosure or privilege escalation.

Why it matters to the business

Systems using kernels with the vulnerable saa7164 driver and compatible SAA7164-based PCIe media/capture hardware could be crashed by a local user or by conditions that force device memory mapping failure. The practical business risk is service disruption on affected Linux hosts, especially where the host provides video capture, media processing, or appliance-like workloads. This vulnerability is not listed in CISA KEV, is not associated with ransomware use, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, exposed multi-user systems or systems where untrusted users can interact with kernel device drivers should still be updated during normal patch cycles.

How an attack unfolds

An attacker first needs local access to a Linux system running a vulnerable kernel with the saa7164 driver available and relevant hardware or device binding conditions present. The attacker attempts to cause the saa7164 device initialization path to run while ioremap() fails for BAR0 or BAR2, for example by triggering driver load, device bind, or reinitialization under conditions where kernel virtual memory mapping fails. In the vulnerable code path, the driver assumes the mapping succeeded and continues initialization. Subsequent access through the failed mapping can dereference a NULL pointer, leading to a kernel oops or panic and denying service to workloads on the host. There is no public indication of active exploitation, named threat actor use, or weaponized exploit maturity for this issue.

How to fix it

Upgrade to a Linux kernel build that includes the saa7164 fix adding ioremap() return-value checks and cleanup handling in saa7164_dev_setup(). If vendor fixed package versions are not yet available, apply the latest stable kernel update from the operating system vendor or distribution once it incorporates the upstream fix. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the saa7164 module if it is not required, removing or disabling affected SAA7164-based PCIe media hardware where feasible, and restricting local shell access to trusted users. Example mitigation: add a modprobe blacklist entry for the saa7164 driver, then rebuild initramfs if the distribution requires it and reboot, but only if the driver is not operationally needed.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor release containing the fix, or by checking the kernel source/package changelog for the saa7164 ioremap return-check patch. Validate that the mitigation is effective by confirming the saa7164 module is not loaded when it is not needed, for example with lsmod or modprobe configuration review. On systems that require the driver, confirm the device initializes cleanly after reboot and that kernel logs do not show saa7164-related oops, NULL pointer dereference, failed BAR mapping, or device setup errors. Because no exact fixed versions were provided, rely on distribution advisories, kernel package changelogs, or upstream stable backport notes for authoritative fixed-version confirmation.

Typical attack path

1. Obtain local low-privileged access to a Linux host running a vulnerable kernel.
2. Confirm the saa7164 media driver is present, loadable, or already bound to compatible PCIe media hardware.
3. Trigger driver initialization, rebinding, or device setup for the saa7164 device.
4. Induce or rely on an ioremap() failure for BAR0 or BAR2 during saa7164_dev_setup().
5. Cause the vulnerable driver path to continue after the failed mapping and dereference invalid state.
6. Crash the kernel or destabilize the affected host, resulting in denial of service.

How to detect it

To determine whether this was already triggered, review kernel and system logs for crashes or oops events involving the saa7164 driver, especially around module load, PCI device enumeration, device bind/unbind, boot, resume, or media hardware initialization. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump records, kdump/vmcore analysis, and system reboot history. Look for NULL pointer dereferences, kernel oops/panic messages, stack traces referencing saa7164_dev_setup or saa7164, BAR0/BAR2 mapping failures, and unexplained reboots after saa7164 module activity. Also review audit or shell history where available for local attempts to load, unload, bind, or unbind the saa7164 module. There are no known network indicators for this local kernel-driver issue.

• saa7164_dev_setup
• saa7164
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• ioremap
• BAR0
• BAR2
• modprobe saa7164
• insmod saa7164
• rmmod saa7164
• /sys/bus/pci/drivers/saa7164/bind
• /sys/bus/pci/drivers/saa7164/unbind
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Inventory Linux systems that have the saa7164 driver available or loaded, especially hosts with SAA7164-based PCIe capture/media hardware.
• Prioritize patching affected multi-user systems, production appliances, media-processing hosts, and systems where untrusted local users can execute code.
• Apply the latest vendor-supported kernel update that includes the saa7164 ioremap failure-handling fix.
• If the driver is not required, blacklist or remove the saa7164 module as a compensating control.
• Monitor kernel logs for saa7164 initialization failures, NULL pointer dereferences, kernel oops events, and unexpected reboots until patching is complete.
• Treat this as a local availability issue rather than a remote compromise issue; no KEV listing, ransomware association, or mature public exploit is currently indicated.