CVE-2026-63933

What it actually does

This is a local denial-of-service flaw in the Linux kernel Industrial I/O gyroscope driver for ADIS16260-class devices. The driver’s write_raw handling for the sampling_frequency sysfs attribute used the supplied frequency value as a divisor without first rejecting zero. A local user or process with permission to write that sysfs attribute can write 0 and trigger a kernel division-by-zero fault, which may cause a kernel oops, driver failure, system instability, or a crash depending on kernel configuration and error handling.

Why it matters to the business

Systems using affected Linux kernels with the vulnerable ADIS16260 IIO gyroscope driver exposed can be destabilized by a local actor or misbehaving privileged process. The primary operational risk is loss of availability for embedded, industrial, sensor, robotics, IoT, or appliance-like Linux systems that rely on this hardware or driver. The current EPSS is low and the issue is not listed in CISA KEV, so widespread exploitation is not indicated, but impacted devices should still be patched during normal kernel maintenance because the flaw can crash production systems where the driver is present.

How an attack unfolds

An attacker first needs local access to a Linux system where the ADIS16260 IIO gyroscope driver is loaded and a writable sampling_frequency sysfs attribute exists for the device. The attacker enumerates IIO devices under sysfs, identifies the relevant device, and writes the value 0 to the sampling_frequency attribute. In vulnerable kernels, the driver accepts the zero value and later uses it as a divisor while processing the write operation. This triggers a division-by-zero exception in kernel context, producing a kernel oops or potentially crashing the host. Exploitation does not require memory corruption primitives or remote network access, but it does require write permission to the relevant sysfs file, which is commonly restricted to root or privileged service contexts.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the ADIS16260 driver validation bug. Because no product-specific fixed versions were provided, use the fixed kernel supplied by the relevant Linux distribution, appliance vendor, embedded board vendor, or kernel maintenance branch. If immediate patching is not possible, mitigate by preventing the vulnerable driver from loading when the hardware is not required, restricting local administrative access, limiting write access to IIO sysfs attributes, and monitoring or controlling services that can write to /sys/bus/iio/devices/*/sampling_frequency. Do not rely on changing sysfs permissions alone as a complete fix, because package updates, udev rules, or device reinitialization may restore defaults.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the ADIS16260 patch that rejects zero sampling_frequency values before division. Check the active kernel version against the vendor advisory or changelog, and confirm the driver source or package changelog contains the validation fix for iio: gyro: adis16260 write_raw. On non-production test systems with the relevant hardware or driver present, attempting to write 0 to the affected sampling_frequency attribute should return an error rather than producing a kernel oops. Also verify whether the module is loaded with lsmod or modinfo, and whether affected sysfs attributes exist under /sys/bus/iio/devices/.

Typical attack path

1. Gain local shell access or execute code through a privileged local service on a Linux system.
2. Check whether the ADIS16260 IIO gyroscope driver is present or loaded.
3. Enumerate IIO sysfs devices under /sys/bus/iio/devices/.
4. Identify a device exposing a sampling_frequency attribute associated with the vulnerable driver.
5. Write the value 0 to the sampling_frequency sysfs attribute.
6. Trigger a kernel divide-by-zero fault, causing a kernel oops, driver failure, system instability, or system crash.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and endpoint telemetry for divide-by-zero or kernel oops events involving the ADIS16260 driver. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries from the kernel facility, kdump/vmcore records, pstore/ramoops logs on embedded systems, and auditd or EDR telemetry for writes to sysfs. Look for local commands or processes writing the literal value 0 to /sys/bus/iio/devices/*/sampling_frequency shortly before a crash, reboot, oops, or watchdog reset. If audit rules were not already in place, post-incident evidence may be limited to kernel exception traces and reboot/crash artifacts. Correlate suspicious kernel faults with user login, sudo, container escape, maintenance scripts, udev rules, or sensor-management services active at the same time.

• /sys/bus/iio/devices/*/sampling_frequency
• echo 0 > /sys/bus/iio/devices/
• sampling_frequency
• adis16260
• iio: gyro: adis16260
• write_raw
• divide error: 0000
• divide error
• division by zero
• kernel BUG
• Oops:
• RIP:
• Call Trace:
• Kernel panic - not syncing
• watchdog: BUG: soft lockup
• pstore
• ramoops
• vmcore
• kdump

What your security team should do

• Prioritize inventory of Linux systems using IIO sensor hardware, embedded platforms, industrial devices, robotics systems, or custom kernels where the ADIS16260 driver may be enabled.
• Apply vendor kernel updates that include the ADIS16260 sampling_frequency validation fix during the next maintenance window, sooner for safety-critical or high-availability embedded systems.
• If the driver or hardware is not needed, disable or blacklist the adis16260 driver to remove the exposed attack surface.
• Restrict privileged shell access and service accounts that can write to sysfs device attributes.
• Review kernel logs for recent divide-by-zero, oops, or panic events referencing adis16260, write_raw, or sampling_frequency.
• Add monitoring for unexpected writes of 0 to IIO sampling_frequency attributes where auditd, eBPF, or endpoint telemetry is available.
• For custom kernel builds, backport the upstream validation check and confirm it is included in deployed images.