CVE-2026-31749: comedi: ni_atmio16d: Fix invalid clean-up after failed attach
In the Linux kernel, the following vulnerability has been resolved:
comedi: niatmio16d: Fix invalid clean-up after failed attach
If the driver's COMEDI "attach" handler function (atmio16dattach()) returns an error, the COMEDI core will call the driver's "detach" handler function (atmio16ddetach()) to clean up. This calls resetatmio16d() unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call resetatmio16d(). It uses dev->iobase as the I/O port base address and dev->private as the pointer to the COMEDI device's private data structure. dev->iobase may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. dev->private may still be NULL, which would result in null pointer dereferences.
Fix atmio16ddetach() by checking that dev->private is valid (non-null) before calling resetatmio16d(). This implies that dev->iobase was set correctly since that is set up before dev->private.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Compensating control
In the Linux kernel comedi ni_atmio16d driver, update atmio16d_detach() to verify that dev->private is non-null before calling reset_atmio16d().
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel with the COMEDI ni_atmio16d driver are exposed when that driver's attach operation fails. The issue occurs in the error-cleanup path rather than during normal successful attachment.
What is required to trigger the problem?
An attacker or local user needs to cause atmio16d_attach() to return an error after the COMEDI attach handler has begun but before all device fields are initialized. The affected cleanup then calls reset_atmio16d() with a potentially null dev->private pointer or an iobase value of 0.
What is the impact of a failed attach on an affected system?
The cleanup path can dereference a null pointer, causing a denial of service. It can also write to unintended low I/O port addresses when dev->iobase remains at its initial value of 0.
What change resolves the issue?
The fix makes atmio16d_detach() verify that dev->private is non-null before calling reset_atmio16d(). Because dev->iobase is set before dev->private, this check also ensures the I/O base was initialized before reset is attempted.