EUVD-2026-35120
GHSA-93h7-7gph-6j69
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local access required (hardware-specific driver); low privileges suffice to trigger unload; kernel panic yields high availability loss with zero confidentiality or integrity impact.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
media: renesas: vsp1: Fix NULL pointer deref on module unload
When unloading the module on gen 4, we hit a NULL pointer dereference. This is caused by the cleanup code calling vsp1_drm_cleanup() where it should be calling vsp1_vspx_cleanup().
Fix this by checking the IP version and calling the drm or vspx function accordingly, the same way as the init code does.
AnalysisAI
NULL pointer dereference in the Linux kernel's Renesas VSP1 media driver crashes the kernel during module unload on Generation 4 Renesas SoC hardware. The defect exists because the cleanup path unconditionally invokes vsp1_drm_cleanup() rather than vsp1_vspx_cleanup() for gen 4 IP versions, while the initialization path correctly checks the IP version - an asymmetry introduced when gen 4 support was added. With an EPSS of 0.02% (4th percentile), no KEV listing, and no public exploit code, real-world exploitation risk is very low and confined to niche embedded and automotive platforms; vendor-released patches are available in stable kernel branches.
Technical ContextAI
The Renesas VSP1 (Video Signal Processor 1) is a hardware IP block embedded in Renesas SoCs, primarily used in automotive and industrial embedded systems, and exposed to the Linux kernel through the media subsystem under drivers/media/platform/renesas/vsp1/. The driver supports two distinct runtime configurations: a DRM (Direct Rendering Manager) path and a VSPX path, selected based on the IP generation detected at probe time. On Generation 4 hardware the VSPX path is used, which allocates and initializes state that the DRM path does not. When the module is unloaded, the cleanup code mistakenly calls vsp1_drm_cleanup() for all configurations instead of branching on IP version, causing a NULL pointer dereference because the gen 4 DRM state structures were never populated. CWE-476 (NULL Pointer Dereference) precisely describes the root cause: a pointer is dereferenced in a code path that was never responsible for initializing it. CPE cpe:2.3:a:linux:linux:* covers the upstream kernel tree; the flaw was introduced at commit d06c1a9f348d22478c6bc5684f9c990e15ada1e9.
RemediationAI
Upgrade to a patched kernel release: Linux 6.18.32, Linux 7.0.9, or Linux 7.1-rc1 (mainline). The upstream fix patches are available directly from the kernel stable tree at https://git.kernel.org/stable/c/58b1e9664d8f74d55d8411cc7a7b275a76a6f24f (6.18 series), https://git.kernel.org/stable/c/bfb2081ba00afbbd15a5ed1ed1acdc3edeea5a98 (7.0 series), and https://git.kernel.org/stable/c/c4bb1515b26663e5230603892e67f2cc7df9f0ca (mainline). Distribution maintainers for Renesas-targeted BSPs (e.g., Yocto/Poky layers) should apply the relevant backport. For systems that cannot be patched immediately, blacklisting or preventing runtime unload of the vsp1 kernel module (e.g., via /etc/modprobe.d/ or building the driver as built-in rather than as a module) eliminates the vulnerable unload code path; the trade-off is that this prevents dynamic driver removal during system maintenance or hotplug events. Restricting CAP_SYS_MODULE to privileged users only raises the bar but does not eliminate risk if low-privileged users can trigger device removal through udev/hotplug.
Same weakness CWE-476 – NULL Pointer Dereference
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today