CVE-2026-31749

What it actually does

This is a local Linux kernel availability flaw in the COMEDI ni_atmio16d driver cleanup path. If the driver's attach routine fails before the COMEDI device is fully initialized, the detach routine can call reset_atmio16d() with uninitialized state: dev->private may be NULL and dev->iobase may still be 0. That can cause a kernel NULL pointer dereference and potentially unintended writes to low I/O port addresses. The practical impact is local denial of service through a kernel oops or panic, especially on systems configured to panic on oops.

Why it matters to the business

A user or process with local access sufficient to trigger COMEDI device attachment can crash or destabilize affected Linux systems, causing service interruption, failed jobs, or downtime on hosts using the affected kernel and driver. The risk is narrower than a network-exploitable issue because exploitation requires local privileges and a specific kernel driver path, and current EPSS is very low with no known KEV listing or public exploit maturity. Organizations that use Linux systems connected to COMEDI-supported data acquisition hardware should prioritize patching according to operational criticality.

How an attack unfolds

An attacker first needs local access to an affected Linux system and the ability to interact with COMEDI driver configuration or device attachment paths. They then cause the ni_atmio16d driver's atmio16d_attach() routine to fail at a point before the COMEDI private data structure is allocated or before the device is fully initialized. The COMEDI core subsequently invokes atmio16d_detach() as part of failure cleanup. In vulnerable kernels, the detach handler unconditionally calls reset_atmio16d(), which assumes initialized state. If dev->private is NULL, the kernel may dereference a NULL pointer; if dev->iobase remains 0, cleanup may perform writes to unintended low I/O ports. The likely result is a kernel oops, crash, or panic, producing a local denial-of-service condition rather than code execution or data disclosure.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream fix for the COMEDI ni_atmio16d detach cleanup path. Where exact fixed package versions are not available from the CVE record, use distribution security advisories and kernel changelogs to identify the first fixed kernel for each supported platform. If immediate patching is not possible, reduce exposure by unloading and blacklisting the ni_atmio16d module where it is not required, disabling unused COMEDI support, restricting access to COMEDI device nodes and configuration utilities to trusted administrators, and preventing untrusted users from loading kernel modules. Systems that do not build, load, or use this driver are generally not exposed to the vulnerable code path.

How to confirm the fix worked

Confirm the running kernel has been updated to a build containing the fix that checks dev->private before reset_atmio16d() is called from atmio16d_detach(). Validate with the distribution's package metadata, kernel changelog, or source diff for drivers/comedi/drivers/ni_atmio16d.c. Check whether the affected module is present or loaded using standard module inventory methods such as lsmod and modinfo for ni_atmio16d. If mitigation rather than patching is used, confirm the module is unloaded, blacklisted, and cannot be loaded by unprivileged users. Review dmesg or journal logs after testing normal COMEDI attach/detach workflows to ensure there are no kernel oops, NULL pointer dereference, or ni_atmio16d cleanup errors.

Typical attack path

1. Obtain local access to an affected Linux host with the vulnerable kernel and COMEDI ni_atmio16d driver available.
2. Gain permission to load, configure, or interact with COMEDI device attachment functionality.
3. Trigger an ni_atmio16d attach operation that fails before full driver initialization completes.
4. Allow the COMEDI core to invoke the driver's detach cleanup handler after the failed attach.
5. Cause atmio16d_detach() to call reset_atmio16d() with incomplete state, leading to NULL pointer dereference, invalid I/O port activity, kernel oops, or system panic.
6. Use the resulting crash or instability to disrupt workloads or availability.

How to detect it

Look for evidence of kernel crashes or instability associated with the COMEDI ni_atmio16d driver. Primary log sources are kernel ring buffer output, system journal entries, syslog/kern.log, crash dump metadata, kdump/vmcore records, and reboot reason telemetry. Search for oops or panic events that mention atmio16d_attach(), atmio16d_detach(), reset_atmio16d(), ni_atmio16d, or COMEDI around the time of unexpected reboots or service interruptions. Also review command history, audit logs, and process execution telemetry for use of COMEDI configuration utilities or module-loading commands shortly before the crash. Because this flaw does not create a stable file, network, or registry artifact, detection is based primarily on kernel crash signatures and local driver interaction activity.

• ni_atmio16d
• atmio16d_attach
• atmio16d_detach
• reset_atmio16d
• comedi
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• Unable to handle kernel NULL pointer dereference
• drivers/comedi/drivers/ni_atmio16d.c
• /dev/comedi
• /dev/comedi0
• modprobe ni_atmio16d
• insmod ni_atmio16d
• comedi_config

What your security team should do

• Prioritize remediation on Linux systems that use COMEDI-supported data acquisition hardware or allow local users to configure COMEDI devices.
• Patch affected kernels through the relevant Linux distribution or kernel vendor; track the fix in drivers/comedi/drivers/ni_atmio16d.c when vendor fixed versions are not explicitly listed.
• If the driver is not required, disable exposure by unloading and blacklisting ni_atmio16d and removing unnecessary COMEDI functionality from custom kernels.
• Restrict local access to COMEDI configuration tools and device nodes to trusted administrators only.
• Monitor kernel logs for ni_atmio16d, COMEDI attach/detach failures, NULL pointer dereferences, oops events, and unexpected reboots.
• Because EPSS is low, there is no KEV listing, and exploitation is local, schedule remediation based on the criticality of affected hosts, but treat shared multi-user systems and operational technology/data acquisition systems as higher priority.