CVE-2026-63967

What it actually does

This is an information disclosure flaw in the Linux kernel Industrial I/O STMicroelectronics LSM6DSx IMU driver. In the tagged FIFO buffer path, a stack-allocated structure is not fully initialized before data is copied to userspace. Because padding bytes between sample data and the timestamp may contain stale stack contents, a local userspace process able to read from the affected IIO device may receive a small amount of unintended kernel stack memory. The flaw does not directly provide code execution or privilege escalation, but it can expose kernel memory values that may assist other attacks.

Why it matters to the business

Systems using affected Linux kernels with ST LSM6DSx IMU sensor support may leak small fragments of kernel memory to local users. The operational risk is generally low because exploitation requires local access to the sensor interface and only discloses limited data, but embedded, mobile, IoT, industrial, and appliance products using this driver should still patch as part of normal kernel maintenance. The vulnerability is not listed in CISA KEV, has no known ransomware association, and currently has low EPSS likelihood, reducing immediate internet-scale urgency.

How an attack unfolds

An attacker first needs local ability to interact with the affected Industrial I/O sensor device exposed by the Linux kernel. They trigger reads from the tagged FIFO path of the ST LSM6DSx IMU driver. Because the stack buffer used for the sample is aligned but not zero-initialized, padding bytes in the structure may retain prior kernel stack contents. When the driver copies the sample-sized buffer to userspace, those uninitialized bytes are included. The attacker repeatedly reads samples and analyzes the leaked bytes for useful kernel memory fragments, addresses, or sensitive remnants that could help bypass hardening or support a chained local exploit.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the ST LSM6DSx tagged FIFO stack initialization issue. Where vendor kernels are used, apply the distribution, appliance, Android, embedded Linux, or hardware vendor kernel update that backports the fix. If immediate patching is not possible, reduce exposure by disabling unused ST LSM6DSx IMU hardware support, preventing the affected kernel module from loading where not required, or restricting local access to Industrial I/O device nodes through permissions, udev rules, containers, SELinux/AppArmor policy, or device cgroup controls. Because no exact fixed package versions were provided, use the relevant vendor advisory or kernel changelog to identify the first build containing the zero-initialization fix for the tagged FIFO buffer.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel package includes the fix that zero-initializes the tagged FIFO stack buffer in the st_lsm6dsx driver. Validate by checking the installed kernel package version against the vendor advisory, reviewing the source or backport patch for initialization of the affected buffer, and confirming that systems have rebooted into the patched kernel. For exposure validation, determine whether the st_lsm6dsx driver is built into the kernel or loaded as a module, whether compatible ST LSM6DSx IMU hardware is present, and whether local users can access the relevant /dev/iio and /sys/bus/iio interfaces.

Typical attack path

1. Gain local code execution or shell access as an unprivileged user on a system exposing the affected IIO sensor device.
2. Identify accessible Industrial I/O device nodes associated with the ST LSM6DSx IMU driver.
3. Enable or read from the tagged FIFO buffer path for the sensor.
4. Collect repeated sample reads returned from the kernel driver.
5. Inspect padding bytes in returned samples for leaked kernel stack data.
6. Use any useful memory disclosure as reconnaissance or as part of a chained local privilege-escalation attempt.

How to detect it

There are no reliable forensic indicators that prove exploitation because the issue is a local kernel memory disclosure through normal sensor reads and is unlikely to produce distinctive logs. To investigate possible abuse, review local audit logs, EDR telemetry, and shell histories for unusual or repeated access to Industrial I/O device nodes, especially /dev/iio:device* and related /sys/bus/iio/devices entries associated with ST LSM6DSx sensors. Look for untrusted processes opening IIO character devices, enabling buffers, changing scan elements, or performing high-volume reads. Kernel logs may help confirm driver presence but are not expected to record exploitation. If stronger visibility is required, use auditd, eBPF, or EDR file/device access monitoring to track opens and reads against IIO device nodes by unexpected users or processes.

What your security team should do

• Prioritize patching affected embedded, mobile, IoT, industrial, and appliance systems that expose ST LSM6DSx IMU devices to untrusted local users or applications.
• Track vendor kernel advisories and deploy the first kernel build containing the tagged FIFO zero-initialization fix.
• Inventory systems with the st_lsm6dsx driver enabled or loaded and confirm whether corresponding IIO device nodes are accessible.
• Restrict access to Industrial I/O device nodes to only trusted services and users until patched.
• Disable or blacklist the st_lsm6dsx driver on systems that do not require the sensor functionality.
• Treat this primarily as a hardening and information-leak issue; monitor for chaining with local privilege-escalation vulnerabilities rather than standalone remote compromise.