Linux Kernel CVE-2026-43397

Exploitation requires local shell access with at minimum low-privilege credentials (CVSS PR:L) on a Linux system where the samsung-dsim DRM bridge kernel module is loaded and Samsung MIPI DSI display hardware is present. The vulnerable code path (samsung_dsim_host_attach()) executes only during display bridge attach events - device initialization, hotplug, or driver rebind - meaning the attacker must be able to trigger these events repeatedly and reliably induce a failure in either samsung_dsim_register_te_irq() or pdata->host_ops->attach() to cause persistent memory accumulation. Systems without Samsung DSI hardware or without the samsung-dsim module loaded are entirely unaffected. The CVSS vector (AV:L/AC:L) indicates no network access or elevated complexity is required once local access is established, but the hardware-specific dependency is the primary limiting factor for real-world exploitation scope.

The CVSS 5.5 score (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly characterizes this as a local, low-complexity issue requiring only low-privilege access, with impact confined entirely to availability - no confidentiality or integrity loss. EPSS at 0.02% (5th percentile) strongly corroborates the low real-world exploitation likelihood. The vulnerability is not listed in CISA KEV and no public POC has been identified. Notably, the source data tags this as 'Information Disclosure,' which conflicts directly with the CVSS vector (C:N) - this appears to be a misclassification; the actual impact is memory exhaustion leading to denial of service only. The vulnerability is further constrained to hardware-specific deployments (Samsung DSI display hardware) with the samsung-dsim module active, making mass exploitation implausible. This is a low-priority kernel hygiene fix relevant primarily to embedded, mobile, and Samsung SoC-based Linux systems.

A local user with a low-privilege shell on a Linux system equipped with Samsung MIPI DSI display hardware triggers repeated samsung_dsim_host_attach() calls, deliberately inducing failures in the TE IRQ registration or host attach operation - for example, by manipulating device state or resource availability. Each failed attach cycle leaks the drm_bridge allocation without reclaim, and over many iterations the accumulated leaked memory exhausts kernel heap, resulting in system instability or a denial of service. No public exploit code has been identified at time of analysis.