Cloudanix VulnDB

CVE-2026-98664

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel's handling of certain sensor files can cause crashes when those files are read at the exact moment the sensor device is being removed.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in adis16400 debugfs handling where serial_number file uses open-coded implementation without debugfs_file_get, allowing debugfs_remove_recursive to proceed while a read is active and free the underlying iio_dev.

Why it matters to the business

Systems using ADIS16400-family IMUs may experience kernel instability or crashes during module unload or device removal when debugfs entries are accessed, increasing operational risk in sensor-heavy deployments.

How an attack unfolds

A local attacker opens the serial_number debugfs file for reading while concurrently triggering device unbind or driver removal; the kernel then dereferences the already-freed iio_dev structure, resulting in a use-after-free condition.

How to fix it

Apply the upstream fix that replaces debugfs_create_file_unsafe with debugfs_create_file for the serial_number entry in the adis16400 driver; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Inspect the adis16400 driver source to confirm serial_number uses debugfs_create_file and that DEFINE_DEBUGFS_ATTRIBUTE is not applied to it; test device removal while holding an open debugfs read.

Typical attack path

  1. Obtain local shell or equivalent access on target system
  2. Open the adis16400 serial_number debugfs file for reading
  3. Trigger concurrent unbind or debugfs_remove_recursive on the device
  4. Kernel accesses freed memory during the in-progress read

How to detect it

Search kernel logs and crash dumps for adis16400 oops or use-after-free reports that coincide with device unbind or module removal operations.

What your security team should do

  • Prioritize kernel update for any system exposing ADIS16400 debugfs entries
  • Restrict local debugfs access via mount options or SELinux policies until patched
  • Monitor kernel logs for adis16400-related oops during device removal events

The record

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.

Affected packages

Ecosystem Package Introduced Fixed