Bug 2464435 (CVE-2026-31749)

Summary: CVE-2026-31749 kernel: comedi: ni_atmio16d: Fix invalid clean-up after failed attach
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the `ni_atmio16d` driver within the Comedi (Comedi is a collection of drivers for data acquisition equipment) subsystem of the Linux kernel. This vulnerability occurs when an error during the driver's attach process causes the cleanup function (`atmio16d_detach()`) to be called with uninitialized device data. This can lead to undesired writes to low I/O port addresses or null pointer dereferences, potentially resulting in system instability or a denial of service (DoS) for a local user.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-01 15:06:40 UTC 
In the Linux kernel, the following vulnerability has been resolved:

comedi: ni_atmio16d: Fix invalid clean-up after failed attach

If the driver's COMEDI "attach" handler function (`atmio16d_attach()`)
returns an error, the COMEDI core will call the driver's "detach"
handler function (`atmio16d_detach()`) to clean up.  This calls
`reset_atmio16d()` unconditionally, but depending on where the error
occurred in the attach handler, the device may not have been
sufficiently initialized to call `reset_atmio16d()`.  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 `atmio16d_detach()` by checking that `dev->private` is valid
(non-null) before calling `reset_atmio16d()`.  This implies that
`dev->iobase` was set correctly since that is set up before
`dev->private`.
Comment 1 Keith Grant 2026-05-01 22:01:31 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026050142-CVE-2026-31749-e7d2@gregkh/T