CVE-2026-63934

What it actually does

This is a Linux kernel information disclosure flaw in the Industrial I/O ITG3200 gyroscope driver. The vulnerable code passes the address of a local pointer variable to i2c_transfer() instead of the caller-provided scan buffer, causing an 8-byte I2C read to overwrite the wrong stack location. As a result, the triggered buffer path does not receive real gyroscope or temperature readings and instead pushes uninitialized kernel stack contents to userspace through /dev/iio:deviceX. The direct read_raw() path is not affected. Practical exploitation requires the vulnerable driver to be present and in use, an ITG3200-compatible I2C device or platform configuration exposing the IIO device, and local userspace access to the relevant IIO character device or buffer interface.

Why it matters to the business

The main business risk is unintended leakage of small amounts of kernel memory to local users, which could expose sensitive runtime data or help bypass exploit mitigations when chained with other vulnerabilities. Operationally, systems relying on ITG3200 buffered gyroscope or temperature readings may receive invalid data, affecting telemetry, robotics, embedded sensing, industrial devices, or test platforms using this driver. The vulnerability is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity, so urgency is generally lower than for remotely exploitable kernel flaws, but affected embedded or multi-user Linux systems should still be patched during the next appropriate maintenance window.

How an attack unfolds

An attacker with local access first determines whether the system exposes an ITG3200-backed Industrial I/O device. They then enable or read from the triggered buffer associated with /dev/iio:deviceX. Each scan causes the kernel driver to attempt an I2C transfer into the wrong stack address and later push the caller's uninitialized scan buffer to userspace. By repeatedly reading the IIO buffer, the attacker may collect small fragments of stale kernel stack memory. Those fragments may not be directly useful on their own, but they can assist further exploitation by revealing kernel data values, pointers, layout hints, or sensitive adjacent state, depending on build configuration and runtime conditions.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the ITG3200 driver, specifically the change that removes the erroneous ampersand so the I2C transfer writes into the caller-provided buffer rather than the local pointer slot. If using a distribution kernel, apply the vendor-provided security or stable kernel update once available. If maintaining a custom kernel, backport the patch to drivers/iio/gyro/itg3200*. As mitigations where patching is delayed, disable or unload the ITG3200 driver if not required, remove access to affected IIO character devices from untrusted users, restrict membership in groups that can read /dev/iio:deviceX, disable the affected buffered capture path where feasible, and avoid exposing affected devices inside containers or multi-tenant environments.

How to confirm the fix worked

Confirm the running kernel contains the fixed ITG3200 driver source or vendor patch. For source-based validation, verify that itg3200_read_all_channels() passes the scan buffer pointer itself to the I2C message destination rather than casting and passing the address of the local pointer variable. For package-based validation, compare the installed kernel package against the distribution advisory once available. For exposure validation, check whether the ITG3200 driver is built, loaded, or bound to hardware, and whether any /dev/iio:deviceX node maps to an ITG3200 device. Functional validation can include reading from the triggered buffer and confirming that values correspond to expected sensor data rather than unstable or unrelated stack-like bytes, though this should be done only in controlled testing.

Typical attack path

1. Gain local userspace access to a Linux system using the ITG3200 Industrial I/O gyroscope driver.
2. Identify exposed IIO devices under /sys/bus/iio/devices/ and corresponding /dev/iio:deviceX nodes.
3. Confirm that an IIO device name or driver binding corresponds to ITG3200.
4. Enable or interact with the triggered buffer interface for the affected device.
5. Repeatedly read scan data from /dev/iio:deviceX.
6. Extract uninitialized stack bytes returned in place of expected gyroscope or temperature samples.
7. Use any leaked values to support further local exploitation, defeat memory-layout defenses, or gather sensitive runtime information.

How to detect it

There is no reliable network indicator for this vulnerability and exploitation may not produce distinctive kernel logs. Detection should focus on exposure and suspicious local access. Review asset inventory, kernel configuration, loaded modules, device tree or ACPI bindings, and sysfs entries to determine whether the ITG3200 IIO driver is present and bound. Check file access telemetry, auditd, eBPF, EDR, or shell history for processes repeatedly opening or reading /dev/iio:deviceX, especially by users or services that do not normally consume sensor data. Inspect /sys/bus/iio/devices/iio:device*/name for ITG3200-related names and correlate the device number to /dev/iio:deviceX access events. Kernel logs may show IIO device registration or driver binding but are unlikely to show successful exploitation. If forensic collection is needed, preserve audit logs, process execution history, device-node access records, and container runtime configuration showing whether IIO devices were exposed to workloads.

• /dev/iio:device
• /sys/bus/iio/devices/iio:device*/name
• /sys/bus/iio/devices/iio:device*/buffer/enable
• itg3200
• ITG3200
• itg3200_read_all_channels
• drivers/iio/gyro/itg3200
• iio_push_to_buffers_with_timestamp

What your security team should do

• Inventory Linux systems, especially embedded, robotics, industrial, lab, and sensor platforms, for ITG3200 or compatible IIO gyroscope usage.
• Prioritize patching affected multi-user systems or systems where untrusted users, containers, or applications can access IIO device nodes.
• Apply vendor kernel updates or backport the upstream driver fix into custom kernels.
• Restrict permissions on /dev/iio:deviceX and related sysfs buffer controls to trusted users only.
• Disable or blacklist the ITG3200 driver on systems that do not require it.
• Review container and sandbox configurations to ensure IIO character devices are not unnecessarily passed through.
• Monitor for unexpected access to IIO device nodes, especially repeated reads from /dev/iio:deviceX by non-sensor applications.
• Treat this primarily as a local information leak that may become more serious when chained with another kernel or local privilege-escalation vulnerability.