CVE-2026-43300

What it actually does

This is a local Linux kernel denial-of-service vulnerability in the DRM panel driver path for JDI MIPI DSI panels. The vulnerable remove routine checks whether the driver state pointer is NULL, but then continues execution and passes a derived object into jdi_panel_disable(), where the NULL-derived panel structure is dereferenced unconditionally. If the vulnerable code path is reached, the kernel can trigger a NULL-pointer dereference, causing an oops or panic depending on kernel configuration and error handling. The impact is availability loss only; the provided CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and no confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash an affected Linux system or destabilize devices using the vulnerable JDI panel DRM driver, leading to downtime, service interruption, device resets, or loss of availability for workloads running on affected hosts. The risk is most relevant to systems that include or load the affected display panel driver, such as embedded Linux, mobile, appliance, or specialized hardware builds. It is not listed in CISA KEV, has no known exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local users or compromised low-privilege accounts on affected systems could still use the flaw to cause operational disruption.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient privileges to exercise the vulnerable driver removal path, or they must already have compromised a local low-privilege account that can trigger device unbind, removal, or teardown behavior for the affected MIPI DSI panel driver. The attacker then causes jdi_panel_dsi_remove() to run in a state where the driver data pointer is NULL. Because the function does not return immediately after detecting the NULL condition, execution continues into jdi_panel_disable(), which dereferences the invalid object. The result is a kernel NULL-pointer dereference that can produce a kernel oops or panic, depending on kernel settings, causing a denial of service. There is no indication from the supplied data that this vulnerability enables code execution, privilege escalation, data theft, ransomware activity, or remote exploitation.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the upstream fix for the DRM panel JDI remove-path NULL-pointer dereference. Because no exact fixed versions were provided, use the corrected kernel packages from the relevant Linux distribution, device vendor, or kernel maintenance branch and verify that the patch returning early from jdi_panel_dsi_remove() when the JDI panel state is NULL is included. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected JDI panel driver on systems that do not require it, restricting local shell access, limiting permissions to sysfs driver bind/unbind interfaces, preventing untrusted users from loading or unloading kernel modules, and applying standard kernel hardening settings that reduce the blast radius of local denial-of-service bugs.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree contains the fixed jdi_panel_dsi_remove() logic that returns immediately after mipi_dsi_detach(dsi) when the JDI panel state pointer is NULL. Validate the deployed kernel version against vendor advisories or distribution changelogs for this CVE. On source-based or custom kernels, inspect drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c or the relevant JDI panel driver source for the corrected control flow. Confirm affected driver exposure by checking whether the relevant DRM panel JDI driver is built into the kernel or loaded as a module, and whether hardware using that panel is present. After patching, monitor dmesg and kernel logs during device removal/unbind testing to ensure no NULL-pointer dereference, kernel oops, or panic occurs.

Typical attack path

1. Gain local access to an affected Linux system, or compromise a low-privilege local account.
2. Identify that the system is running a vulnerable Linux kernel build with the affected DRM JDI MIPI DSI panel driver present or loadable.
3. Trigger the affected panel driver removal, detach, or unbind path so that jdi_panel_dsi_remove() executes while its driver data pointer is NULL.
4. The kernel continues past the NULL check and calls jdi_panel_disable() with an invalid object reference.
5. The NULL-pointer dereference causes a kernel oops, panic, display subsystem failure, or full system crash, resulting in denial of service.

How to detect it

To determine whether this flaw was already triggered, review kernel logs and persistent system journals for NULL-pointer dereference, kernel oops, BUG, panic, or call traces involving the JDI panel DRM driver remove/disable path. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel records, pstore/ramoops crash logs on embedded systems, crash dumps captured by kdump, and device watchdog reset logs. Look specifically for call traces referencing jdi_panel_dsi_remove(), jdi_panel_disable(), panel-jdi-fhd-r63452, mipi_dsi_detach(), drm_panel_disable(), and backlight_disable(). Also review audit logs and shell history, where available, for recent writes to sysfs driver unbind/bind files or attempts to remove display-related kernel modules shortly before a crash. Because this is a denial-of-service condition rather than a persistence or code-execution flaw, durable host artifacts may be limited to crash traces, reboot records, and evidence of local activity that triggered driver teardown.

• NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• BUG: kernel NULL pointer dereference
• jdi_panel_dsi_remove
• jdi_panel_disable
• panel-jdi-fhd-r63452
• mipi_dsi_detach
• drm_panel_disable
• backlight_disable
• /sys/bus/mipi-dsi/drivers
• /sys/bus/platform/drivers
• /sys/bus/*/drivers/*/unbind
• /sys/bus/*/drivers/*/bind
• drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c

What your security team should do

• Prioritize patching affected embedded, mobile, appliance, kiosk, workstation, or specialized Linux systems that use JDI MIPI DSI display panels or custom kernels with the affected DRM panel driver enabled.
• Use vendor-supported kernel updates rather than ad hoc source modifications where possible, and ensure reboot into the fixed kernel is completed after installation.
• For custom kernel builds, cherry-pick the upstream DRM panel fix and rebuild, test, sign, and deploy kernels through the normal release process.
• Restrict local interactive access and administrative capabilities on affected systems, especially access to sysfs driver bind/unbind controls and kernel module management.
• If the affected hardware or display panel driver is not needed, disable the driver in the kernel configuration or blacklist the module as a temporary mitigation.
• Add monitoring for kernel oops, panic, NULL-pointer dereference, and JDI panel driver errors so potential exploitation or accidental triggering is visible to operations teams.
• Treat unexplained crashes on devices using this panel driver as potentially security-relevant until logs confirm an alternative root cause.