CVE-2026-31751

What it actually does

This is a local Linux kernel denial-of-service flaw in the COMEDI dt2815 driver. A low-privileged local user who can issue the COMEDI_DEVCONFIG ioctl can request that the dt2815 driver attach to arbitrary I/O port addresses. Before the fix, the driver could proceed with output operations even when no dt2815 hardware existed at the specified port. Reads from a floating bus may return 0xff, but subsequent outb() writes to non-existent or invalid hardware state can trigger a kernel page fault, Oops, or panic. The practical technical impact is loss of system availability; the issue is not described as enabling data disclosure or privilege escalation.

Why it matters to the business

The main risk is unplanned downtime on Linux systems where COMEDI and the dt2815 driver are present and reachable by local users or workloads. Because exploitation requires local access, high attack complexity, and specific driver exposure, broad internet-scale risk is low. EPSS is very low and stable, the vulnerability is not in CISA KEV, and no public exploit maturity is reported, so this should generally be prioritized below remotely exploitable kernel flaws. However, affected systems used for lab automation, industrial data acquisition, research instrumentation, or shared compute environments may experience service interruption if an untrusted user or automated test workload triggers the crash.

How an attack unfolds

An attacker first obtains local code execution on a Linux host where the COMEDI subsystem and dt2815 driver are available. The attacker identifies or opens a COMEDI device interface and issues the COMEDI_DEVCONFIG ioctl to attach the dt2815 driver to an arbitrary I/O base address where no dt2815 hardware is actually present. On vulnerable kernels, the driver does not reliably detect the missing hardware before performing port I/O. The initial status read can return 0xff from the floating bus, but the driver may still proceed into write operations. Under the right conditions, those outb() operations cause a kernel fault in dt2815_attach(), resulting in an Oops, panic, or system crash. The attacker’s end goal is denial of service rather than persistence or data theft.

How to fix it

Upgrade to a kernel package that includes the dt2815 hardware-detection fix: the corrected driver reads the status register first and fails attach with -ENODEV when it sees 0xff, instead of attempting write operations against absent hardware. Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or kernel vendor advisory to identify the first fixed kernel for each maintained branch. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the dt2815 module if it is not required, disabling unused COMEDI support, restricting access to /dev/comedi* device nodes to trusted administrators or service accounts, and limiting the ability of untrusted users to load kernel modules. Systems that do not include COMEDI/dt2815 or do not expose COMEDI device configuration to local users are not practically exposed to this flaw.

How to confirm the fix worked

Confirm the running kernel is from a vendor build that contains the dt2815 attach hardware-detection change. Validate package status with distribution tools such as rpm, dpkg, apt, yum, dnf, zypper, or the vendor appliance update mechanism, and compare against the relevant advisory. Check whether exposure exists by reviewing kernel configuration and loaded modules for COMEDI and dt2815 support, for example with lsmod, modinfo, /proc/config.gz, or /boot/config-$(uname -r). Confirm that /dev/comedi* device nodes are absent or restricted if COMEDI is not required. In a controlled non-production test environment only, an attach attempt against a non-existent dt2815 I/O port should fail cleanly with ENODEV and should not generate a kernel Oops, panic, or fault in dt2815_attach().

Typical attack path

1. Gain local access to a Linux system as a low-privileged user or through an already-compromised local workload.
2. Confirm that COMEDI support and the dt2815 driver are installed, loadable, or already loaded.
3. Access a COMEDI device node or otherwise reach the COMEDI_DEVCONFIG ioctl path.
4. Submit a device configuration request that attaches the dt2815 driver to an arbitrary or non-existent I/O port address.
5. Trigger the vulnerable attach path so the driver reads a floating bus value and then attempts unsafe port write operations.
6. Cause a kernel page fault, Oops, panic, or reboot, resulting in denial of service.

How to detect it

Look for evidence of local attempts to configure COMEDI devices followed by kernel faults. Primary sources are kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, system crash dumps, kdump/vmcore artifacts, and persistent kernel logs such as pstore/ramoops. Search for Oops, panic, page fault, or supervisor write access messages with stack traces involving dt2815_attach, comedi, COMEDI_DEVCONFIG, inb(), or outb(). If auditd or eBPF syscall monitoring is enabled, review ioctl activity against /dev/comedi* device nodes around the time of crashes, especially from unexpected users, shells, fuzzers, or test harnesses. Because successful exploitation may crash the system before logs are flushed, also inspect reboot timelines, watchdog resets, hypervisor power events, and crash dump metadata for unexplained kernel failures. There are no network indicators because exploitation is local.

• dt2815_attach
• COMEDI_DEVCONFIG
• /dev/comedi
• /dev/comedi0
• BUG: unable to handle page fault
• supervisor write access in kernel mode
• #PF: error_code(0x0002)
• RIP: 0010:dt2815_attach
• comedi: dt2815
• dt2815
• unable to handle page fault for address
• kernel BUG
• Oops
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems for COMEDI and dt2815 driver availability, prioritizing shared multi-user systems, lab systems, industrial or instrumentation hosts, and systems that allow untrusted local workloads.
• Patch affected systems to a vendor kernel release containing the dt2815 hardware-detection fix.
• If the driver is unused, blacklist or remove the dt2815 module and disable unnecessary COMEDI functionality.
• Restrict permissions on /dev/comedi* device nodes and ensure only trusted users can perform COMEDI device configuration.
• Review kernel logs, pstore, crash dumps, and monitoring alerts for recent Oops or panic events referencing dt2815_attach or COMEDI_DEVCONFIG.
• Tune SOC priority appropriately: no KEV listing, no known ransomware use, no reported exploit maturity, and very low stable EPSS indicate low external exploitation likelihood, but local denial-of-service risk remains relevant on exposed shared systems.