CVE-2026-31751: comedi: dt2815: add hardware detection to prevent crash
In the Linux kernel, the following vulnerability has been resolved:
comedi: dt2815: add hardware detection to prevent crash
The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDIDEVCONFIG ioctl.
When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions:
BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page RIP: 0010:dt2815attach+0x6e0/0x1110
Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.
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 comedi dt2815 driver, read the hardware status register before any write operation; if the read returns 0xff, treat the hardware as absent and fail the attach with -ENODEV.
Event History
Frequently Asked Questions
Who can trigger the crash?
A local user or process able to invoke the COMEDI_DEVCONFIG ioctl and attach the dt2815 driver to an arbitrary I/O port address can trigger the condition. Exploitation requires choosing an address where no actual hardware is present.
What happens when the driver is attached to a nonexistent device?
Reads from the floating I/O bus return 0xff, while subsequent outb() operations can cause a kernel page fault, particularly under race conditions. The result is a denial of service through a kernel crash.
How does the resolved code prevent the issue?
The driver reads the status register before performing write operations. If the value is 0xff, it treats the hardware as absent and rejects the attach request with -ENODEV.