CVE-2026-46310: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46310 Overview

CVE-2026-46310 is a NULL pointer dereference vulnerability in the Linux kernel's Renesas VSP1 media driver. The flaw occurs during module unload on Renesas Gen 4 hardware. The cleanup path calls vsp1_drm_cleanup() unconditionally instead of dispatching to vsp1_vspx_cleanup() when the IP version requires the VSPX cleanup routine. The mismatch dereferences a NULL pointer and crashes the kernel.

Critical Impact
Local users with the ability to unload the vsp1 kernel module can trigger a NULL pointer dereference, resulting in a kernel oops and denial of service on affected Renesas Gen 4 platforms.

Affected Products

Linux kernel — media: renesas: vsp1 driver
Renesas Gen 4 hardware platforms using the VSP1 driver
Kernel branches receiving the fixes referenced in the upstream stable commits

Discovery Timeline

2026-06-08 - CVE-2026-46310 published to the National Vulnerability Database (NVD)
2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46310

Vulnerability Analysis

The vulnerability resides in the Renesas VSP1 video processing driver inside drivers/media/platform/renesas/vsp1/. The driver supports multiple Renesas SoC generations, and initialization branches between a DRM (Direct Rendering Manager) pipeline and a VSPX pipeline based on the detected intellectual property (IP) version. The init path correctly dispatches to either vsp1_drm_init() or vsp1_vspx_init() depending on hardware generation.

The cleanup path, however, calls vsp1_drm_cleanup() for all variants. On Gen 4 hardware that uses the VSPX pipeline, the DRM-specific state was never initialized, so internal pointers remain NULL. When vsp1_drm_cleanup() walks those structures, it dereferences a NULL pointer and panics the kernel.

The upstream resolution adds the missing IP-version check to the teardown sequence and routes cleanup to vsp1_vspx_cleanup() when VSPX is in use, mirroring the existing init logic.

Root Cause

The defect is an asymmetric cleanup routine in the vsp1 driver. Initialization is hardware-aware; teardown is not. This is a classic NULL pointer dereference [CWE-476] caused by a missing branch in the unload path, not by attacker-supplied input.

Attack Vector

Triggering the bug requires the ability to unload the vsp1 kernel module on a Renesas Gen 4 system. Module unload typically requires CAP_SYS_MODULE, so the issue is local and privileged. The resulting kernel oops produces a denial of service. No code execution or memory corruption primitive is documented in the upstream commits.

No verified public proof-of-concept code is available. The vulnerability is described in the upstream stable kernel commits referenced by the Kernel Git Commit Log.

Detection Methods for CVE-2026-46310

Indicators of Compromise

Kernel oops messages referencing vsp1_drm_cleanup in the call trace after a rmmod vsp1 or driver teardown event
Unexpected crashes or reboots on Renesas Gen 4 platforms when media subsystems are reinitialized
dmesg entries showing a NULL pointer dereference in the drivers/media/platform/renesas/vsp1/ code path

Detection Strategies

Inventory Renesas Gen 4 systems running affected Linux kernel versions and confirm whether the vsp1 module is loaded
Audit which users or services hold CAP_SYS_MODULE and can invoke rmmod or modprobe -r
Compare installed kernel build hashes against the fixed commits 58b1e9664d8f, bfb2081ba00a, and c4bb1515b266

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a central log store and alert on BUG: unable to handle kernel NULL pointer dereference events involving vsp1
Monitor kmod events for unexpected unload of media drivers on embedded Renesas devices
Track kernel package versions across fleets to confirm patches are deployed

How to Mitigate CVE-2026-46310

Immediate Actions Required

Apply the upstream stable kernel patches referenced in the kernel git commit log on all Renesas Gen 4 systems
Restrict CAP_SYS_MODULE to required administrative accounts only, and prevent unprivileged module unloads
Avoid manual unloading of the vsp1 module on unpatched Gen 4 hardware until the fix is in place

Patch Information

The fix updates the vsp1 driver teardown logic to dispatch between vsp1_drm_cleanup() and vsp1_vspx_cleanup() based on the IP version, matching the init code. The corrective commits are published in the upstream stable tree: commit 58b1e9664d8f, commit bfb2081ba00a, and commit c4bb1515b266. Rebuild and redeploy the kernel, or install the vendor-provided kernel package that includes these commits.

Workarounds

Keep the vsp1 module loaded for the lifetime of the system to avoid invoking the buggy cleanup path
Blacklist module unload via modprobe configuration where the VSP1 driver is not required for the workload
Limit physical and remote root access to embedded Renesas Gen 4 devices to reduce the chance of a triggered unload

bash

# Verify the running kernel includes the fix commit
uname -r
zcat /proc/config.gz | grep -i VIDEO_RENESAS_VSP1

# Prevent unprivileged or scripted unload of the vsp1 module
echo 'blacklist_unload vsp1' >> /etc/modprobe.d/vsp1.conf