CVE-2026-46313

What it actually does

This flaw is an error-pointer dereference in the Linux kernel Intel IPU6 media driver during PCI device probe error handling. In a specific failure path, the driver treats an ERR_PTR value as though it were a valid psys object and dereferences it, which can trigger a kernel oops or panic. The practical impact is denial of service on systems that include the affected Intel IPU6 driver and hardware or otherwise load and probe the vulnerable driver path. There is no indication from the supplied data that this enables privilege escalation, data theft, or remote code execution.

Why it matters to the business

Affected Linux systems may crash or become unavailable if the vulnerable Intel IPU6 driver error path is triggered. The greatest operational risk is to laptops, workstations, kiosks, edge devices, or embedded Linux systems using Intel IPU6 camera/media hardware where unexpected kernel crashes can interrupt users, workloads, or device fleets. Current public exploitation likelihood appears low: EPSS is 0.00114, it is not in CISA KEV, not associated with ransomware use, and no exploit maturity is reported. However, kernel denial-of-service flaws should still be addressed through normal patch cycles because they can cause outages and may be easier to trigger in environments where local users or device-management workflows can reload or rebind hardware drivers.

How an attack unfolds

An attacker would first need access to a Linux system where the vulnerable Intel IPU6 media driver is present and can be made to probe an IPU6 PCI device. The attacker then needs a way to cause the driver initialization path to hit the relevant error-handling branch, such as by triggering device unbind/rebind, module load/unload, or hardware reprobe under conditions that make psys initialization fail. When the error path is reached, the driver dereferences an error pointer instead of clearing it before cleanup. That dereference can cause a kernel oops or panic, resulting in a local denial of service. This is not a typical network-exploitable vulnerability; exploitation generally depends on local privileges, device-management access, physical/device access, or another mechanism that can influence kernel driver probing.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the fix for the Intel IPU6 driver error-pointer dereference. If no fixed package version is provided by the platform vendor yet, track the vendor kernel advisory and update to the first kernel release that incorporates the upstream fix in drivers/media/pci/intel/ipu6/ipu6.c. Where IPU6 camera/media functionality is not required, reduce exposure by disabling or blacklisting the Intel IPU6 driver, preventing unnecessary module loading, or disabling the related hardware in firmware settings where operationally acceptable. Restrict permissions for kernel module loading, PCI device bind/unbind, and device-management interfaces to trusted administrators only. Treat mitigations as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm that the running kernel has been updated to a vendor build containing the IPU6 driver fix, not merely that the package is installed. Validate with distribution package metadata, vendor advisory references, uname -a, and reboot status. Check whether exposure exists by looking for IPU6 hardware and driver presence using tools such as lspci, lsmod, modinfo, kernel configuration, and /sys/bus/pci/drivers/. In a non-production test environment, validate that loading, unloading, binding, or rebinding the IPU6 device no longer produces kernel oops or panic messages. Review dmesg or journalctl -k after reboot and driver initialization to confirm there are no IPU6 probe crashes or stack traces referencing ipu6_pci_probe.

Typical attack path

1. Identify a Linux host with Intel IPU6 media hardware or the vulnerable IPU6 driver enabled.
2. Confirm the vulnerable driver can be loaded, unloaded, rebound, or otherwise forced through PCI probe logic.
3. Induce or wait for a failure during IPU6 psys initialization so the driver enters the affected cleanup path.
4. Trigger driver probe or reprobe, such as through module operations, PCI device bind/unbind, or device reset workflows.
5. Cause the driver to dereference the ERR_PTR value during cleanup.
6. Crash the kernel or produce a kernel oops, causing service interruption or system reboot depending on panic settings.

How to detect it

To determine whether this issue was already triggered, review kernel and system logs for crashes, oops reports, panic events, watchdog resets, or unexpected reboots that coincide with Intel IPU6 driver initialization, device probing, module loading, or PCI bind/unbind activity. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore artifacts, systemd journal reboot history, audit logs for privileged writes to /sys/bus/pci/drivers/, and command history or EDR telemetry showing modprobe, rmmod, insmod, or driverctl activity involving IPU6 modules. Focus forensic review on stack traces that mention ipu6_pci_probe, drivers/media/pci/intel/ipu6/ipu6.c, Intel IPU6, or ERR_PTR-style dereference symptoms. Because exploitation primarily manifests as a kernel crash rather than a persistent compromise, absence of files or network indicators does not rule out triggering; correlate crash timing with local privileged activity and device-management events.

• ipu6_pci_probe
• drivers/media/pci/intel/ipu6/ipu6.c
• intel/ipu6
• Intel IPU6
• ERR_PTR
• dereferencing possible ERR_PTR
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel NULL pointer dereference
• Oops:
• Kernel panic
• RIP: ipu6_pci_probe
• Call Trace: ipu6_pci_probe
• /sys/bus/pci/drivers
• /sys/bus/pci/drivers/*/bind
• /sys/bus/pci/drivers/*/unbind
• modprobe ipu6
• rmmod ipu6
• insmod ipu6
• driverctl

What your security team should do

• Prioritize patching systems that have Intel IPU6 hardware, load the IPU6 media driver, or are used as shared workstations, kiosks, edge devices, or other systems where local denial of service has high operational impact.
• Inventory Linux assets for Intel IPU6 hardware and loaded IPU6-related kernel modules before assigning emergency priority across the entire fleet.
• Apply the vendor-supported kernel update and reboot into the fixed kernel; verify the running kernel version after reboot.
• If patching is delayed and IPU6 functionality is not business-critical, temporarily disable or blacklist the affected IPU6 driver or disable the hardware through approved configuration management.
• Limit local administrative capabilities that allow module loading, PCI device bind/unbind, driver reprobe, or direct device manipulation.
• Monitor kernel logs for oops, panic, or stack traces involving ipu6_pci_probe or Intel IPU6 components, especially on systems with unexpected reboots.
• Because this issue is not KEV-listed, has no reported exploit maturity, and has very low EPSS, handle it through risk-based kernel maintenance unless local DoS on affected device classes is especially disruptive.