CVE-2026-43484

What it actually does

This is a Linux kernel race condition in the MMC core. The kernel stored the MMC host claim state and retune-control state as bitfields sharing the same underlying word. In asynchronous paths, concurrent read-modify-write updates to one flag could unintentionally overwrite another flag. Under the right timing, this can corrupt the MMC host state and trigger kernel warnings such as WARN_ON(!host->claimed), potentially leading to a kernel crash, hang, or loss of availability for systems using MMC/eMMC/SD storage. The vulnerability requires local access with low privileges and does not provide confidentiality or integrity impact by itself.

Why it matters to the business

An attacker or malfunctioning local workload could cause affected Linux systems that use MMC, eMMC, or SD-backed storage to become unstable or unavailable. The most likely business impact is service interruption, device reboot, embedded appliance instability, or operational downtime. Risk is highest for laptops, embedded Linux devices, appliances, IoT systems, and servers that boot from or rely on MMC/eMMC/SD storage. This issue is not listed in CISA KEV, has no known exploit maturity, and has a very low EPSS score, so remediation should be prioritized based on exposure to local users and operational criticality rather than evidence of active exploitation.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system. They then attempt to exercise MMC request and retuning paths concurrently, for example by generating sustained storage I/O against an MMC/eMMC/SD device while triggering timing-sensitive conditions that cause host-claim and retune flags to be updated at the same time. Because the vulnerable kernel stores these related state flags in a shared bitfield word, one asynchronous update can overwrite another. If the race is won, the kernel can observe an impossible MMC host state, such as retune processing occurring while the host no longer appears claimed, causing WARN_ON conditions and possible system instability or denial of service. There is no indication from the provided data that this flaw is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the upstream MMC core fix moving claimed, can_retune, retune_now, and retune_paused out of the shared bitfield word and into independent boolean fields. Because no exact fixed versions were provided, use vendor advisories for the specific Linux distribution, appliance, embedded SDK, or kernel tree in use. For custom kernels, backport the upstream patch for 'mmc: core: Avoid bitfield RMW for claim/retune flags'. If immediate patching is not possible, reduce exposure by limiting local shell/container access, restricting untrusted users from running arbitrary workloads on affected systems, minimizing access to MMC/eMMC/SD-backed devices, and applying operational safeguards such as watchdog recovery for embedded systems. Mitigations do not fully remove the underlying race; kernel update or backport is the recommended fix.

How to confirm the fix worked

Confirm the running kernel includes the MMC core change that converts the affected claim and retune flags from shared bitfields to separate boolean fields. On vendor-supported systems, verify the installed kernel package version against the distribution or appliance security advisory. On source-built kernels, inspect the MMC host structure and related code paths to confirm claimed, can_retune, retune_now, and retune_paused are no longer implemented as coupled bitfields sharing the same word. Reboot into the fixed kernel and verify with uname -a or package-manager output that the active kernel is the patched build. For exposure validation, identify systems with MMC/eMMC/SD devices using lsblk, /sys/class/mmc_host, dmesg, or hardware inventory data; systems without MMC-host usage are much less likely to be practically affected.

Typical attack path

1. Obtain local, low-privileged access to a Linux system running an affected kernel.
2. Confirm the system uses an MMC, eMMC, or SD storage path handled by the Linux MMC core.
3. Generate high-frequency storage operations that exercise MMC queue request handling.
4. Induce or wait for retune-related activity to occur concurrently with MMC host-claim state changes.
5. Trigger the bitfield read-modify-write race so one flag update overwrites another unrelated flag.
6. Cause a kernel warning, crash, hang, or storage subsystem disruption resulting in denial of service.

How to detect it

Look for evidence of abnormal MMC subsystem behavior and kernel instability. Useful log sources include kernel ring buffer output, persistent kernel logs, system journal entries, crash dumps, netconsole output, appliance diagnostic bundles, and reboot/panic records. Search for WARN_ON, kernel oops, panic, hung task, or storage reset events involving MMC host claim or retune activity. Focus on timelines where a local user or workload generated unusually heavy I/O to MMC/eMMC/SD devices before a crash or reboot. Because the issue is a race condition in kernel state handling, there may be no reliable attacker-specific artifact; detection is primarily based on suspicious combinations of local activity, MMC/eMMC/SD stress, and kernel warnings or denial-of-service symptoms. Absence of these logs does not prove the vulnerability was not triggered, especially if volatile kernel logs were lost during reboot.

• WARN_ON(!host->claimed)
• host->claimed
• mmc_mq_queue_rq
• __mmc_claim_host
• retune_now
• retune_paused
• can_retune
• mmc: core
• mmc_host
• /sys/class/mmc_host
• kernel: WARNING
• kernel: BUG
• kernel: panic
• kernel: Oops
• hung task
• mmc0:
• mmc1:
• mmc2:

What your security team should do

• Inventory Linux systems that use MMC, eMMC, or SD storage, including embedded devices, appliances, laptops, and edge systems.
• Prioritize patching where local users, containers, or untrusted workloads can execute code on systems with MMC/eMMC/SD-backed storage.
• Track vendor kernel advisories and deploy the first kernel release that includes the MMC core bitfield race fix.
• For custom or embedded kernels, backport the upstream MMC patch and validate it through stress testing of storage I/O and suspend/resume or retune-heavy workloads.
• Restrict local interactive access and arbitrary workload execution on unpatched systems, especially multi-user or container-hosting systems.
• Monitor kernel logs for MMC warnings, host-claim assertion failures, unexplained storage resets, kernel oops events, panics, or reboots.
• Treat repeated MMC-related WARN_ON events or crashes as potential exploitation or stability incidents and preserve kernel logs for analysis.