CVE-2026-64503

What it actually does

This is a local denial-of-service/power-management flaw in the Linux kernel kxsd9 IIO accelerometer driver. When kxsd9_write_raw() handles an invalid scale write with a non-zero integer component, it returns an error before releasing a runtime power-management reference acquired with pm_runtime_get_sync(). Each failed write leaks one runtime PM usage-counter reference, preventing the accelerometer device from autosuspending. The practical technical effect is persistent device wakefulness, increased power consumption, and possible battery drain or thermal impact on systems using this driver. It does not indicate memory corruption, privilege escalation, or remote code execution.

Why it matters to the business

Organizations with Linux systems that include and use the kxsd9 accelerometer driver may see reduced battery life, higher power draw, and degraded reliability on embedded, mobile, industrial, or edge devices. The risk is limited by the need for local ability to write to the affected IIO sysfs control, but it can still matter for fleets where untrusted local users, containers with excessive device access, or applications can interact with sensor controls. The CVE is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and currently has no public exploit maturity, so remediation should be handled through normal kernel patch management rather than emergency response unless affected devices are exposed to untrusted local workloads.

How an attack unfolds

An attacker first needs local access to a system where the kxsd9 accelerometer driver is loaded and an IIO sysfs interface for the device is present. The attacker then identifies the writable scale attribute for the accelerometer and submits an invalid scale value whose integer portion is non-zero. The driver takes a runtime PM reference, rejects the value, and exits before decrementing the runtime PM usage counter. Repeating this operation accumulates leaked PM references. Once the counter is imbalanced, the device remains active and can no longer autosuspend normally, causing avoidable power consumption and potentially contributing to battery drain or device instability over time.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the kxsd9 driver runtime PM imbalance in kxsd9_write_raw(). If no fixed package version is provided by the vendor yet, track kernel advisories for this CVE or for the patch titled "iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error." Where immediate patching is not possible, reduce exposure by unloading or blacklisting the kxsd9 driver if the accelerometer is not required, restricting write permissions to IIO sysfs attributes, reviewing udev rules that grant sensor access, and avoiding device passthrough to untrusted containers or sandboxed workloads. Rebooting or reloading the driver may clear the accumulated runtime PM imbalance, but this is only a temporary operational recovery and not a fix.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for the kxsd9 runtime PM reference leak. On potentially affected systems, verify whether the kxsd9 driver is loaded using module inventory or kernel configuration checks, and check for corresponding IIO devices under /sys/bus/iio/devices/. After patching, a controlled test can write an invalid scale value to the relevant accelerometer scale attribute and confirm that the device still enters runtime autosuspend afterward. Use kernel power-management tracing, ftrace runtime PM events, powertop, or vendor-specific power telemetry to verify that repeated invalid writes no longer leave the device permanently active. Also confirm that sysfs permissions and udev rules do not allow untrusted users or containers to write to sensor control attributes unnecessarily.

Typical attack path

1. Gain local shell, application-level code execution, or other ability to write to the affected IIO device sysfs attributes.
2. Confirm that the kxsd9 accelerometer driver is present and that an IIO device exposes writable accelerometer scale controls.
3. Write an invalid accelerometer scale value with a non-zero integer component to the relevant IIO scale attribute.
4. Repeat the invalid write to leak additional runtime PM references.
5. Leave the device in a state where runtime autosuspend no longer works, increasing power draw until the device, driver, or system is reset or patched.

How to detect it

To determine whether this was already abused, focus on local activity against IIO sysfs attributes rather than network indicators. Review auditd, EDR, eBPF file-write telemetry, shell history, and application logs for repeated writes to accelerometer scale attributes under /sys/bus/iio/devices/. Look for users or processes repeatedly writing invalid scale values to files such as in_accel_scale or similarly named accelerometer scale controls. Correlate that activity with kernel logs, power-management traces, battery telemetry, powertop data, or device monitoring that shows the kxsd9 device failing to autosuspend after the writes. If audit rules were not already in place for sysfs writes, historical confirmation may be difficult; absence of logs should not be treated as proof of non-exploitation. There are no known public threat actors or ransomware campaigns associated with this issue based on the provided data.

• /sys/bus/iio/devices/iio:device*/in_accel_scale
• /sys/bus/iio/devices/iio:device*/in_accel_*_scale
• kxsd9
• kxsd9_write_raw
• pm_runtime_get_sync
• pm_runtime_put_autosuspend
• iio: accel: kxsd9
• write_raw() error

What your security team should do

• Prioritize patching Linux systems that use kxsd9 accelerometers in battery-powered, embedded, industrial, kiosk, mobile, or edge deployments.
• Ask Linux platform owners to confirm whether the kxsd9 driver is built, loaded, or present on managed device images.
• Restrict write access to IIO sysfs sensor attributes to trusted system services only, especially on multi-user systems and container hosts.
• Disable, unload, or blacklist the kxsd9 driver on systems where the hardware is not present or the accelerometer is not operationally required.
• Add monitoring for repeated failed writes to IIO accelerometer scale attributes where auditd, eBPF, or EDR file-write telemetry is available.
• Treat confirmed exploitation primarily as local abuse or misbehaving software causing power-management degradation rather than as evidence of remote compromise.