CVE-2026-43340

What it actually does

This is a local denial-of-service class flaw in the Linux kernel COMEDI subsystem. A COMEDI device structure contains a spinlock reserved for use by attached low-level COMEDI drivers. For legacy COMEDI devices that can be reattached to different low-level drivers through the COMEDI_DEVCONFIG ioctl, the spinlock state was not reinitialized between driver attachments. If CONFIG_LOCKDEP is enabled, switching between drivers that use different locking levels can cause inconsistent lock-state tracking, lockdep warnings, and potentially kernel instability or a panic on systems configured to panic on warnings. The issue does not provide confidentiality or integrity impact and does not imply remote code execution.

Why it matters to the business

An authenticated local user with access to COMEDI device nodes could potentially disrupt systems that expose the COMEDI subsystem, particularly industrial, lab, measurement, or data-acquisition hosts using COMEDI-supported hardware. The main operational risk is system instability or outage, which may interrupt data collection, test equipment, automation workloads, or other host services. Risk is lower for systems that do not load COMEDI, do not create legacy COMEDI minors, do not expose /dev/comedi* to untrusted users, or do not run kernels with CONFIG_LOCKDEP enabled. This CVE is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS, so remediation should be prioritized based on local exposure rather than broad internet exploitation pressure.

How an attack unfolds

An attacker first needs local execution on a Linux system and permission to access a COMEDI device node such as /dev/comedi0. The system must have the COMEDI subsystem available, legacy COMEDI minors enabled through comedi.comedi_num_legacy_minors, and a configuration that permits COMEDI device reconfiguration via the COMEDI_DEVCONFIG ioctl. The attacker repeatedly attaches the same COMEDI device to different low-level COMEDI drivers whose spinlock usage differs. Because the shared comedi_device spinlock was not reinitialized before each new driver attach operation, lockdep may detect contradictory lock states. On affected systems this can produce kernel lock dependency reports, warnings, or instability; if the system is configured with panic_on_warn or similar hardening/debug behavior, the result may be a local kernel panic and denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix reinitializing dev->spinlock before invoking a low-level COMEDI driver's attach function when CONFIG_LOCKDEP is enabled. No exact fixed package versions were provided, so use the relevant distribution or kernel vendor advisory for the corrected kernel version. If immediate patching is not possible, reduce exposure by disabling or unloading unused COMEDI modules, disabling legacy COMEDI minors by ensuring comedi.comedi_num_legacy_minors is zero or unset, restricting permissions on /dev/comedi* device nodes to trusted administrators or service accounts only, and preventing untrusted users from running COMEDI configuration utilities. On systems where COMEDI is not needed, remove the COMEDI driver support from the kernel configuration or blacklist the relevant modules.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor version that includes the fix for this issue. Verify whether COMEDI is built or loaded by checking kernel configuration and loaded modules for CONFIG_COMEDI and comedi-related modules. Check whether legacy COMEDI minors are enabled through /proc/cmdline, modprobe configuration, or sysfs/module parameters for comedi.comedi_num_legacy_minors. Confirm that /dev/comedi* nodes are absent on systems that do not require COMEDI, or have restrictive ownership and permissions on systems that do. For patched validation in a test environment only, attempts to reconfigure legacy COMEDI devices between supported low-level drivers should no longer produce lockdep inconsistent lock-state warnings attributable to dev->spinlock reuse.

Typical attack path

1. Obtain local shell access or run code as a user with permission to open COMEDI device nodes.
2. Identify exposed COMEDI device nodes such as /dev/comedi0 and confirm the host supports COMEDI legacy minors.
3. Use COMEDI configuration tooling or custom code to issue COMEDI_DEVCONFIG ioctl calls against a legacy COMEDI minor.
4. Attach the COMEDI device to one low-level driver and then reattach it to another driver with different spinlock locking behavior.
5. Trigger inconsistent lockdep state reporting, kernel warnings, or instability.
6. If kernel warning policies escalate warnings to panic, cause a local denial of service.

How to detect it

To determine whether this was already exploited, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and crash dumps for lockdep reports or kernel warnings around COMEDI device reconfiguration. Look for sequences where a process opened /dev/comedi* and issued COMEDI_DEVCONFIG shortly before lockdep warnings, kernel oops messages, or a panic. If auditd, eBPF, or endpoint telemetry captures device access or ioctl activity, search for ioctl operations against /dev/comedi* by non-administrative users or unexpected processes. Review shell history, sudo logs, process execution logs, and package/tool usage for COMEDI configuration utilities. Because exploitation is local and does not require network traffic, network indicators are not expected. The strongest evidence is a combination of COMEDI device access, COMEDI_DEVCONFIG activity, and kernel lockdep output showing inconsistent lock state involving COMEDI-related code.

• /dev/comedi
• /dev/comedi0
• /dev/comedi1
• COMEDI_DEVCONFIG
• comedi_config
• comedi.comedi_num_legacy_minors
• inconsistent lock state
• possible circular locking dependency detected
• kernel: BUG:
• kernel: WARNING:
• lockdep
• comedi

What your security team should do

• Inventory Linux hosts for COMEDI exposure, especially systems with /dev/comedi* device nodes or comedi-related kernel modules loaded.
• Prioritize patching hosts that allow non-administrative users to access COMEDI devices, run data-acquisition workloads, or use debug kernels with CONFIG_LOCKDEP enabled.
• Apply the corrected vendor kernel when available and reboot into the fixed kernel.
• Restrict /dev/comedi* permissions to trusted users only and review groups that grant device access.
• Disable COMEDI or legacy COMEDI minors on systems where they are not operationally required.
• Monitor kernel logs for lockdep warnings, COMEDI device reconfiguration activity, and unexpected local ioctl activity against /dev/comedi* devices.
• If kernel warnings or panics were observed, preserve journalctl/dmesg output and investigate local users and processes that accessed COMEDI device nodes before the event.