CVE-2026-43143

What it actually does

This is a local Linux kernel race condition in the MFD core subsystem involving unsynchronized access to the internal mfd_of_node_list list. A local authenticated user or local process able to trigger relevant MFD device registration/removal or device-tree-related code paths may cause concurrent list manipulation without mutual exclusion. The expected impact is kernel instability, including crashes, panics, or denial of service. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, no confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service interruption, workload failure, degraded availability, and potential data loss from abrupt shutdowns. Because exploitation requires local access and there is no known public exploit or CISA KEV listing, broad internet-scale exploitation is unlikely; however, shared Linux platforms, multi-user systems, developer workstations, embedded Linux devices, and infrastructure running untrusted local workloads should treat this as a reliability and availability risk.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system with low privileges. They then repeatedly exercise kernel paths that access or modify the MFD core's device-tree node list, attempting to create concurrent operations against mfd_of_node_list. Because the vulnerable code lacks proper locking around list access, competing execution paths may corrupt list state or dereference inconsistent data. The result is typically a kernel oops, panic, or system crash rather than code execution. No public exploit maturity is reported, EPSS is very low and stable, and there is no known ransomware or KEV activity associated with this vulnerability.

How to fix it

Apply a vendor-provided Linux kernel update that includes the MFD core fix adding mutex protection around mfd_of_node_list access. Because no fixed version was provided in the input, use the fixed kernel packages from the operating system, distribution, appliance, or embedded-device vendor rather than attempting ad hoc patching. After installing the fixed kernel, reboot into the updated kernel and remove or de-prioritize vulnerable older kernels where operationally feasible. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container/device access, disabling unnecessary MFD-related hardware paths where applicable, and monitoring for unexplained kernel crashes or panics.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version after reboot and comparing it against the vendor advisory or package changelog that includes the MFD core locking fix for mfd_of_node_list. On source-based or custom kernels, verify that accesses to mfd_of_node_list are protected by the introduced mutex in the MFD core code. Validate that systems have actually booted into the updated kernel, not merely installed it. Review package manager history, kernel package versions, bootloader defaults, and uname -a output. For exposure detection, inventory Linux systems and map running kernel builds to vendor-fixed releases.

Typical attack path

1. Gain local authenticated access to an affected Linux system or obtain execution inside a local workload/container with sufficient access to trigger relevant kernel device paths.
2. Identify whether the running kernel contains the vulnerable MFD core code.
3. Repeatedly trigger MFD device registration, removal, probing, or device-tree-related operations that access mfd_of_node_list.
4. Race concurrent list access or modification until kernel list state becomes inconsistent.
5. Cause a kernel oops, panic, crash, reboot, or service outage.

How to detect it

To determine whether this may already have been exploited, review kernel logs and crash artifacts for oopses, panics, or reboots associated with the MFD core subsystem and mfd_of_node_list. Relevant sources include journalctl -k, dmesg logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore records, kdump/vmcore output, crash dump analysis, systemd journal reboot history, hypervisor reset events, and endpoint telemetry showing repeated local activity immediately before kernel crashes. Look for repeated crashes on multi-user or untrusted-workload systems, especially if logs contain MFD-related symbols or stack traces near list manipulation. Because exploitation is expected to produce a denial-of-service condition rather than durable malware artifacts, absence of persistent files or processes does not rule it out; focus on crash timing, kernel stack traces, and local user/process activity preceding the crash.

• mfd_of_node_list
• drivers/mfd/mfd-core.c
• mfd_add_devices
• mfd_remove_devices
• mfd: core
• BUG: kernel NULL pointer dereference
• kernel BUG at drivers/mfd/mfd-core.c
• general protection fault
• list_add corruption
• list_del corruption
• kernel panic - not syncing
• Oops:
• /sys/fs/pstore/
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/vmcore

What your security team should do

• Prioritize patching shared Linux servers, virtualization hosts, container hosts, CI/CD runners, developer systems, and any system where untrusted or semi-trusted users can execute local code.
• Install the vendor-fixed kernel and reboot into it; verify the active kernel version after reboot.
• Track distribution and appliance vendor advisories because fixed version names vary by downstream kernel branch and backport policy.
• Limit local access and untrusted workload execution on affected systems until patched.
• Review kernel crash, panic, and reboot telemetry from the period since publication for signs of repeated availability failures.
• For custom kernels, confirm the MFD core patch adding locking around mfd_of_node_list has been applied and tested.
• Keep this vulnerability lower priority than remotely exploitable or actively exploited kernel issues when resources are constrained, given the low EPSS, local attack requirement, and no known KEV status.