CVE-2026-43471

What it actually does

This is a Linux kernel NULL pointer dereference in the UFS storage driver path, specifically in ufshcd_add_command_trace(). When ufshcd_mcq_req_to_hwq() returns NULL, the vulnerable code dereferences hwq->id without first validating that hwq exists. On affected systems using the impacted UFS multi-circular queue code path, a local low-privileged user or local workload that can trigger relevant UFS I/O completion activity may cause a kernel fault and crash. The primary impact is denial of service through kernel panic or device reboot; there is no indicated confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, services, or embedded/mobile devices that rely on UFS storage. The risk is most relevant for systems with UFS storage and the affected kernel driver enabled; systems without UFS hardware or without the impacted driver path are unlikely to be exposed. The CVSS availability impact is high, but EPSS is very low and there is no known KEV listing or public exploit maturity, so remediation should be planned promptly through normal kernel update channels rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system. The attacker then generates storage I/O activity intended to exercise the UFS host controller multi-queue completion path. If the driver reaches a state where ufshcd_mcq_req_to_hwq() returns NULL, the vulnerable trace function still attempts to read the hardware queue identifier. That invalid memory access occurs in kernel context, causing a page fault/oops and potentially a kernel panic, reboot, or device hang depending on kernel panic settings and platform behavior. Exploitation is local and availability-focused; the available information does not indicate a reliable privilege escalation or data disclosure primitive.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the upstream fix for the UFS core NULL check in ufshcd_add_command_trace(). Because no exact fixed package versions were provided, use the kernel versions published by the relevant Linux distribution, device vendor, Android/embedded BSP provider, or hardware platform maintainer. Prioritize systems that use UFS storage, especially ARM/mobile/embedded platforms and servers or appliances with UFS-backed boot or data storage. If immediate patching is not possible, reduce exposure by limiting local shell/container access to trusted users, restricting untrusted workloads on affected systems, and applying operational safeguards such as automatic service recovery and crash monitoring. Systems that do not include or load the affected UFS driver path are lower priority but should still receive kernel updates through standard maintenance.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or vendor firmware includes the patch adding a NULL check before accessing hwq->id in ufshcd_add_command_trace(). Validate the running kernel with uname -a, package manager metadata, vendor advisory references, and source/build provenance where available. Check whether UFS-related modules or drivers are present or loaded, such as ufs, ufshcd, or vendor-specific UFS host drivers. After updating, reboot into the fixed kernel and confirm the active kernel is the patched version, not merely installed. Review dmesg, journald, console logs, crash dumps, and kdump output for absence of new ufshcd_add_command_trace NULL pointer dereference crashes during normal and stress storage I/O testing.

Typical attack path

1. Gain local access to an affected Linux system or run code inside a local user context.
2. Confirm the system uses UFS storage and an affected kernel/driver path.
3. Generate sustained or targeted storage I/O to trigger UFS command completion handling.
4. Cause ufshcd_mcq_req_to_hwq() to return NULL during command tracing.
5. Trigger a NULL pointer dereference in ufshcd_add_command_trace().
6. Crash the kernel or force a reboot, resulting in denial of service.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs and crash artifacts. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, journald kernel facility logs, console logs, pstore/ramoops, kdump/vmcore analysis, Android tombstones/last_kmsg where applicable, and device management crash telemetry. Search for kernel oops, panic, page fault, or NULL pointer dereference events where the stack trace includes ufshcd_add_command_trace(), ufshcd_compl_one_cqe(), ufshcd_mcq_poll_cqe_lock(), ufs_mtk_mcq_intr(), or other UFS host-controller interrupt/completion functions. Correlate crashes with local user sessions, container/job execution, suspicious storage stress activity, repeated device reboots, or abnormal I/O-heavy commands shortly before the crash. Because this vulnerability produces a kernel crash rather than a durable payload, there may be no file-based IOC; detection is primarily crash-signature and timeline based.

• ufshcd_add_command_trace
• ufshcd_compl_one_cqe
• ufshcd_mcq_poll_cqe_lock
• ufs_mtk_mcq_intr
• ufshcd_mcq_req_to_hwq
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• die_kernel_fault
• do_page_fault
• do_translation_fault
• do_mem_abort
• el1_abort
• el1h_64_sync_handler
• __handle_irq_event_percpu
• handle_fasteoi_irq
• generic_handle_domain_irq
• gic_handle_irq
• ufs_mediatek_mod
• /sys/fs/pstore/console-ramoops
• /sys/fs/pstore/dmesg-ramoops
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems and embedded devices that use UFS storage or load UFS host controller drivers.
• Prioritize patching affected UFS-capable systems with local multi-user access, untrusted workloads, kiosk use, mobile/edge deployments, or high availability requirements.
• Apply vendor kernel, firmware, BSP, or distribution updates that include the UFS NULL pointer dereference fix.
• Review kernel crash, dmesg, journald, and kdump telemetry for historical crashes matching ufshcd_add_command_trace, ufshcd_compl_one_cqe, or UFS MCQ interrupt handling.
• Restrict local access and untrusted workload execution on unpatched affected systems until updates are applied.
• Ensure watchdog, service restart, HA failover, and device management controls are configured to recover from unexpected kernel crashes.
• Track vendor advisories for exact fixed kernel builds because fixed versions were not provided in the vulnerability metadata.