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

# 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