CVE-2026-43397

What it actually does

This is a local availability flaw in the Linux kernel Samsung DSIM DRM bridge driver. In samsung_dsim_host_attach(), the driver adds a DRM bridge and then performs additional setup. If later setup steps fail, the error path previously returned without removing the bridge and, in one path, without unregistering the TE IRQ. Repeated triggering of this failure path can leak kernel memory and associated driver state, potentially degrading system stability or causing a denial of service. The flaw requires local access and privileges sufficient to exercise the affected display/DRM driver path; it does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Systems using affected Linux kernels with the Samsung DSIM display bridge driver may become unstable or unavailable if the vulnerable path is repeatedly triggered. The most relevant risk is operational disruption on devices that rely on this display hardware, such as embedded Linux systems, ARM-based platforms, appliances, kiosks, or mobile/IoT-style devices. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and has no reported exploit maturity, so remediation should be handled through normal kernel maintenance unless the affected driver is enabled on production-critical devices.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel and must be able to interact with the DRM/display subsystem in a way that causes samsung_dsim_host_attach() to run. The attacker then attempts to force failure after drm_bridge_add() succeeds, such as during TE IRQ registration or downstream host attach handling. On vulnerable kernels, the function exits without fully undoing the earlier bridge registration and related resources. Repeating this sequence can progressively consume kernel memory or leave stale driver state behind. The likely end result is resource exhaustion, degraded graphics/display behavior, kernel instability, or a local denial of service rather than code execution or data theft.

How to fix it

Upgrade to a Linux kernel version that includes the samsung-dsim error-path fix for samsung_dsim_host_attach(). The fix ensures drm_bridge_remove() is called on all relevant failure paths and samsung_dsim_unregister_te_irq() is called when attach fails after TE IRQ registration. No exact fixed package versions were provided in the input, so use the fixed kernel version supplied by the relevant Linux distribution, hardware vendor, Android/embedded BSP vendor, or upstream stable kernel branch. If immediate patching is not possible, reduce exposure by disabling or unloading the affected Samsung DSIM DRM bridge driver where it is not required, limiting local shell access, restricting untrusted users from interacting with graphics/display device nodes, and applying standard local privilege and device-access controls.

How to confirm the fix worked

Confirm the running kernel contains the upstream or vendor backport for the samsung-dsim host attach cleanup. Validate by checking the installed kernel package changelog, vendor advisory, or source tree for the corrected samsung_dsim_host_attach() error handling that calls drm_bridge_remove() on attach failure paths and unregisters the TE IRQ when needed. On systems where the driver is built as a module, verify whether the affected module is present and loaded using kernel module inventory tooling. Where feasible in a test environment, exercise the Samsung DSIM display attach path and confirm that repeated attach failures do not produce increasing unreclaimed kernel memory, stale DRM bridge objects, or persistent IRQ registrations. Production validation should focus on confirming the patched kernel is booted, not merely installed.

Typical attack path

1. Gain local access to a Linux system using an affected kernel and the Samsung DSIM DRM bridge driver.
2. Identify that the Samsung DSIM display bridge path is present, loaded, or reachable through the platform device/display stack.
3. Trigger the display bridge host attach flow.
4. Cause or induce a failure after drm_bridge_add() succeeds, such as during TE IRQ registration or host_ops attach handling.
5. Repeat the failing attach sequence to accumulate leaked kernel resources.
6. Use the resulting memory pressure or inconsistent driver state to cause display malfunction, system instability, or denial of service.

How to detect it

There are no public reports of exploitation and no distinctive attacker-controlled payload indicators are derivable from the advisory. To assess possible prior exploitation, review kernel logs, system journals, DRM/display subsystem logs, and device health telemetry for repeated Samsung DSIM or DRM bridge attach failures followed by rising kernel memory use, out-of-memory events, display resets, or kernel warnings. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, systemd-oomd or kernel OOM logs, and EDR telemetry showing local users repeatedly accessing DRM/display device nodes. On embedded systems, also review vendor diagnostics, watchdog reset logs, and boot-loop records. Because this vulnerability is a memory leak in a driver error path, evidence is likely to appear as reliability anomalies rather than clear compromise artifacts.

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and ARM platforms that include or enable the Samsung DSIM DRM bridge driver.
• Prioritize patching production-critical devices that use the affected display hardware or expose local interactive access to untrusted users.
• Apply the vendor-provided fixed kernel or BSP update; ensure the patched kernel is the active booted kernel after maintenance.
• If patching is delayed, disable the affected driver or restrict access to local display/DRM device interfaces where operationally feasible.
• Monitor for repeated display subsystem attach failures, kernel memory pressure, unexpected display resets, or local users repeatedly exercising DRM device paths.
• Treat this as a local denial-of-service issue rather than a remote compromise issue unless combined with another vulnerability that grants local access.
• Track vendor advisories because exact fixed versions may vary across Linux distributions, embedded BSPs, and long-term-support kernel branches.