CVE-2026-46310

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel Renesas VSP1 media driver cleanup path. On affected Gen 4 Renesas VSP1/VSPX hardware, unloading the relevant kernel module can call the wrong cleanup routine, causing the kernel to dereference a NULL pointer. The practical technical result is a kernel oops or panic during module unload, leading to local denial of service. Exploitation generally requires the ability to unload kernel modules or otherwise trigger the affected driver teardown path, which is typically restricted to privileged users or administrative automation.

Why it matters to the business

The most likely business impact is unexpected system crash or reboot on devices using affected Renesas VSP1 media hardware, especially embedded, automotive, industrial, appliance, or edge systems where media processing is enabled. Because the issue is not in CISA KEV, has very low EPSS, and has no known public exploit maturity, broad internet-scale exploitation is unlikely; however, operational disruption can still be significant for systems that rely on high availability or unattended operation.

How an attack unfolds

An attacker with sufficient local privileges, or access to an administrative path that can unload kernel modules, identifies a system using the affected Renesas VSP1 driver on Gen 4 hardware. The attacker triggers removal or unload of the VSP1-related kernel module. During driver cleanup, the vulnerable kernel follows the wrong cleanup path and calls the DRM cleanup routine instead of the VSPX cleanup routine for the IP version in use. This causes a NULL pointer dereference in kernel context. Depending on kernel configuration and panic settings, the system may log an oops, terminate the offending kernel path, or panic and reboot, resulting in denial of service.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the Renesas VSP1 cleanup path. If consuming a vendor-maintained kernel, apply the relevant distribution, BSP, or appliance firmware update that backports the fix. No exact package-level fixed versions were provided, so security teams should confirm remediation through the kernel vendor’s advisory, changelog, or commit history for the fix described as correcting the VSP1 Gen 4 module unload cleanup path. If immediate patching is not possible, reduce risk by preventing untrusted users or automation from unloading kernel modules, disabling unnecessary VSP1 media driver functionality where operationally feasible, and limiting shell or administrative access on affected embedded systems.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the vendor kernel changelog, package advisory, or source tree for the corrected cleanup logic that selects vsp1_drm_cleanup() or vsp1_vspx_cleanup() based on IP version. Validate exposure by inventorying systems for Renesas VSP1/VSPX hardware and loaded VSP1-related kernel modules. On a non-production test system only, controlled unload/reload testing of the module should no longer produce a kernel oops, panic, or NULL pointer dereference. Production validation should rely on package/version verification and kernel logs rather than intentionally triggering module unload on critical systems.

Typical attack path

1. Gain local administrative privileges or access to a mechanism that can unload kernel modules or detach the affected device/driver.
2. Confirm the system is running an affected Linux kernel with the Renesas VSP1 media driver and Gen 4 VSP1/VSPX hardware support.
3. Trigger module unload, driver teardown, or a related cleanup path for the affected VSP1 driver.
4. The kernel executes the incorrect cleanup function for the hardware IP version.
5. A NULL pointer dereference occurs in kernel context, causing an oops, panic, crash, or reboot.

How to detect it

To determine whether this issue may have already been triggered, review kernel logs and persistent journal data for oops, panic, or NULL pointer dereference messages around the time of module unloads, device detach events, maintenance windows, or driver reload automation. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility logs, crash dump directories, kdump/vmcore records, and embedded device persistent diagnostic logs. Look specifically for stack traces referencing the Renesas VSP1 driver, vsp1 cleanup functions, media driver removal, or module unload activity immediately preceding a reboot. Because this is a denial-of-service flaw rather than a remote code execution vulnerability, there may be no network IOC; the strongest evidence is kernel crash telemetry tied to VSP1 module teardown.

• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• vsp1_drm_cleanup
• vsp1_vspx_cleanup
• vsp1_remove
• renesas vsp1
• vsp1
• rcar-vsp1
• media: renesas: vsp1
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore
• kdump

What your security team should do

• Prioritize patching or firmware updates for embedded, edge, industrial, or appliance systems using Renesas Gen 4 VSP1/VSPX media hardware.
• Confirm with the Linux distribution, BSP, or device vendor whether their kernel build includes the upstream fix, since no exact fixed package versions were supplied.
• Inventory systems for loaded Renesas VSP1 media drivers and affected hardware before assigning remediation priority.
• Restrict the ability to unload kernel modules to trusted administrators only, and audit any automation that performs driver reloads or hardware reinitialization.
• Monitor kernel logs for NULL pointer dereferences, oopses, or panics involving the VSP1 driver cleanup path.
• Treat confirmed crashes involving this path as a denial-of-service incident, but weigh urgency against the currently low EPSS score, non-KEV status, and lack of known exploit maturity.