CVE-2026-98664: iio: imu: adis16400: fix unprotected debugfs reads
iio: imu: adis16400: fix unprotected debugfs reads
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.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
Update adis16400_serial_number_fops to call debugfs_file_get() for reads, ensuring debugfs_remove_recursive() waits for an in-progress read before unbind frees the iio_dev.
Event History
Frequently Asked Questions
Under what circumstances can this issue occur?
The issue requires a read of the adis16400 serial_number debugfs file to be in progress while the device is being unbound and its IIO device data is freed. The vulnerable path concerns the open-coded serial_number debugfs file.
Are all of the driver's debugfs files affected in the same way?
No. The product_id and flash_count files use DEFINE_DEBUGFS_ATTRIBUTE and are described as self-protecting. The serial_number file is the affected case because it is open coded and did not call debugfs_file_get().
What change resolves the race?
The fix replaces unsafe creation for the affected open-coded debugfs file with debugfs_create_file(). This ensures debugfs_remove_recursive() waits for an in-progress read before device teardown frees the underlying IIO device.