CVE-2026-98664 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis16400: fix unprotected debugfs reads
adis16400_serial_number_fops is open coded and never calls debugfs_file_get(), so debugfs_remove_recursive() does not wait for a read in progress and unbind frees the iio_dev underneath it.
Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but moved all three files to debugfs_create_file_unsafe().
serial_number prints three registers as "%.4x-%.4x-%.4x" and DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be converted without changing what the file returns. adis16475 and adis16550 already use debugfs_create_file() for their open coded files. Use it here too.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified in the industrial IIO IMU driver for ADIS16400 devices represents a critical race condition rooted in improper handling of debugfs file operations. The core issue lies within the adis16400_serial_number_fops implementation, which is open-coded and fails to invoke debugfs_file_get(). This omission breaks the reference counting mechanism that ensures user-space processes holding an open file descriptor are properly tracked by the kernel's debugfs subsystem. Consequently, when a read operation is in progress from this specific debugfs entry, the system does not wait for its completion before proceeding with cleanup routines.
This flaw becomes particularly dangerous during device unbinding or removal scenarios where debugfs_remove_recursive() is called. Because the driver did not increment the reference count via debugfs_file_get(), the kernel assumes no active users of the file exist and proceeds to free the underlying iio_dev structure immediately. This premature deallocation occurs while a user-space process may still be accessing memory mapped by that device, leading to use-after-free conditions. Such race conditions can result in system crashes, data corruption, or potentially allow an attacker with local access to exploit the dangling pointer for arbitrary code execution, depending on the specific kernel state and allocation patterns at the time of exploitation.
The root cause was introduced during a refactoring effort where commit ae1d37a9bb4b converted product_id and flash_count attributes to use DEFINE_DEBUGFS_ATTRIBUTE. While this macro provides built-in protection by managing reference counts correctly, it inadvertently caused all three files in that driver module to be created using debugfs_create_file_unsafe(). The serial_number attribute could not simply adopt the same macro because its output format differs significantly; it prints three registers as a hexadecimal string formatted as "%.4x-%.4x-%.4x", whereas DEFINE_DEBUGFS_ATTRIBUTE is designed for formatting single u64 values. This technical constraint led to the continued use of unsafe file creation methods for this specific entry, leaving it vulnerable despite improvements in adjacent code paths.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution race conditions involving shared resources without proper synchronization. Furthermore, the potential impact falls under CWE-416, Use After Free, as the kernel frees memory that is still being accessed by user-space processes through an open file descriptor. In terms of adversarial tactics, this flaw could be leveraged in ATT&CK technique T1059, Command and Scripting Interpreter, if exploited to gain elevated privileges or disrupt service availability within a Linux-based embedded system utilizing these IMU sensors.
The resolution involves replacing the unsafe debugfs_create_file_unsafe() call with the standard debugfs_create_file() function for the serial_number attribute. This change ensures that the kernel properly increments reference counts when the file is opened and decrements them upon closure, thereby preventing premature deallocation of the iio_dev structure during unbind operations. This fix aligns the behavior of adis16400 with other similar drivers like adis16475 and adis16550, which already employ debugfs_create_file() for their open-coded files, establishing consistency across the driver family.
Mitigation strategies for organizations relying on affected kernel versions include applying upstream Linux kernel patches that address this specific race condition in the iio imu subsystem. For systems where immediate patching is not feasible, restricting access to debugfs interfaces can reduce the attack surface. Since exploitation requires local access to read from these debug files, enforcing strict permissions on /sys/kernel/debug and monitoring for unusual processes attempting to interact with IMU device attributes can provide a layer of defense-in-depth until the software update is deployed.