CVE-2026-43340: Linux Kernel Race Condition Vulnerability

CVE-2026-43340 Overview

CVE-2026-43340 is a medium-severity vulnerability in the Linux kernel's COMEDI (Linux Control and Measurement Device Interface) subsystem. The flaw resides in how struct comedi_device manages its spinlock member across multiple low-level driver attachments. When a COMEDI device is reattached to a different low-level driver via the COMEDI_DEVCONFIG ioctl, inconsistent spin-lock locking states can be reported because each driver may use different locking levels. The issue is observable when CONFIG_LOCKDEP is enabled and can lead to kernel locking inconsistencies that impact system availability. The kernel maintainers resolved this by reinitializing dev->spinlock between attachments.

Critical Impact

A local authenticated user with access to COMEDI device files can trigger kernel lock state inconsistencies through repeated COMEDI_DEVCONFIG ioctl calls, potentially resulting in denial of service.

Affected Products

• Linux Kernel (multiple stable branches)
• Linux Kernel 7.0 release candidates rc1 through rc7
• Systems with the COMEDI subsystem compiled and comedi.comedi_num_legacy_minors set to a non-zero value

Discovery Timeline

• 2026-05-08 - CVE-2026-43340 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43340

Vulnerability Analysis

The COMEDI subsystem provides a kernel interface for data acquisition and control hardware. The central struct comedi_device structure contains a spinlock field initialized once by the COMEDI core but used exclusively by the attached low-level driver. Since the removal of real-time code in commit 25436dc9d84f, this spin-lock has been reserved for low-level driver use only.

COMEDI devices created when the comedi.comedi_num_legacy_minors module parameter is non-zero persist across driver attachments. The COMEDI_DEVCONFIG ioctl allows a privileged user to attach and detach different low-level drivers to the same device over its lifetime. Each driver may acquire dev->spinlock at different contexts, such as hard IRQ, soft IRQ, or process context, creating mismatched lock usage patterns that the kernel's lockdep validator flags as inconsistent.

Root Cause

The root cause is the absence of spin-lock reinitialization between driver attachments. The lockdep subsystem tracks per-lock usage history. When successive drivers acquire the same lock instance under different IRQ contexts, lockdep reports inconsistent lock states and can disable further lock checking, undermining kernel locking guarantees.

Attack Vector

The attack vector is local. An attacker requires sufficient privileges to open the COMEDI device file and invoke the COMEDI_DEVCONFIG ioctl. By alternately attaching low-level drivers that use the device spin-lock from different IRQ contexts, the attacker triggers lockdep warnings and locking state corruption. The impact is limited to availability, with no confidentiality or integrity loss according to the CVSS vector.

No verified public exploit code is available. The fix reinitializes dev->spinlock immediately before invoking each low-level driver's attach function pointer when CONFIG_LOCKDEP is enabled. See the upstream kernel commits for the exact patch implementation.

Detection Methods for CVE-2026-43340

Indicators of Compromise

• Kernel log entries containing lockdep warnings referencing comedi or comedi_device->spinlock inconsistent lock states
• Unexpected user-space invocations of the COMEDI_DEVCONFIG ioctl on /dev/comedi* device nodes from non-administrative processes
• Repeated attach/detach cycles against the same COMEDI minor device within short time windows

Detection Strategies

• Audit running kernel versions against the patched commits listed on git.kernel.org to confirm exposure
• Monitor dmesg and /var/log/kern.log for INFO: inconsistent lock state or WARNING: possible irq lock inversion messages tied to the COMEDI subsystem
• Use auditd rules to log ioctl calls against /dev/comedi* nodes and correlate by user and process

Monitoring Recommendations

• Enable CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING on test systems to surface locking anomalies before production deployment
• Track loading and unloading of COMEDI low-level driver modules through modprobe and rmmod events
• Forward kernel logs to a centralized SIEM and alert on COMEDI-related lockdep warnings

How to Mitigate CVE-2026-43340

Immediate Actions Required

• Apply the latest stable kernel update from your Linux distribution that includes the COMEDI spin-lock reinitialization fix
• Restrict access to /dev/comedi* device nodes using filesystem permissions and group membership controls
• If COMEDI hardware is not in use, unload the comedi module or omit it from the kernel build

Patch Information

The Linux kernel maintainers released fixes across multiple stable branches. The relevant upstream commits include 4d5ffe524903a30e2e0da7d16841a56bec2de55c, 2b1f49e4fdff3ef0f8e9158bbb5b149e06287560, 3181c34b415c5464be9d34bff3e43ef63b747039, 430291d8f3884f57ae0057049b0ca291453e29e1, 4b9a9a6d71e3e252032f959fb3895a33acb5865c, 83134a7a176ce5b4b19b6edecf4360e8d98d1a5a, b89c026227712c367950bbae055a5b31073d3b30, and c01bcc67a9a692d65508ebd480405b5e77d562b7. Consult the Linux kernel stable tree for the patches.

Workarounds

• Set the comedi.comedi_num_legacy_minors module parameter to 0 to prevent creation of legacy COMEDI devices that can be reattached
• Blacklist the comedi module on hosts that do not require data acquisition hardware support
• Limit CAP_SYS_ADMIN and device file access to trusted administrative accounts only

# Disable legacy COMEDI minor devices to avoid reattachment scenarios
echo "options comedi comedi_num_legacy_minors=0" | sudo tee /etc/modprobe.d/comedi.conf

# Or blacklist the module entirely if COMEDI is not required
echo "blacklist comedi" | sudo tee /etc/modprobe.d/blacklist-comedi.conf
sudo update-initramfs -u