CVE-2026-64496

What it actually does

This is a local Linux kernel race condition in the Industrial I/O (IIO) event file descriptor path. The vulnerable sequence installs a newly created anonymous event file descriptor into a process file descriptor table before the IIO event FIFO is reset. Because file descriptor tables can be shared across threads, another thread can access the new descriptor immediately and race a read operation against the FIFO reset. If the race is won, FIFO indexes can become inconsistent, causing a later read to calculate an underflowed length and copy data beyond the intended IIO event FIFO buffer. The primary impact is kernel memory disclosure to a local user-space process; depending on surrounding memory layout and error handling, it may also contribute to kernel instability or denial of service.

Why it matters to the business

An attacker who already has local code execution on a Linux system may be able to read sensitive kernel memory, potentially exposing secrets, credentials, cryptographic material, kernel pointers, or other data that helps defeat hardening and support further privilege escalation. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, and currently has very low EPSS probability, but it affects a privileged boundary in the operating system kernel and should be remediated through normal kernel patching, especially on multi-user systems, shared compute platforms, developer workstations, appliances, and systems exposing IIO devices to untrusted users or containers.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on a vulnerable Linux system with access to the IIO event interface. The attacker creates or uses multiple threads sharing a file descriptor table, then repeatedly invokes the IIO event file descriptor ioctl while another thread guesses or observes the newly allocated descriptor number and rapidly performs reads against it. If the read executes after the descriptor is installed but while the kernel is resetting the event FIFO, the FIFO output index can be advanced using stale state. Subsequent reads may then cause the kernel to treat the FIFO as containing more data than it actually does, copying adjacent kernel memory back to user space. The attacker can repeat the race to collect memory disclosures and may use the leaked data to bypass kernel address randomization or obtain sensitive information useful for follow-on attacks.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix moving the IIO event FIFO reset before the anonymous file descriptor is installed with anon_inode_getfd(). No exact fixed package versions were provided in the input, so use vendor advisories and package changelogs for CVE-2026-64496 or the corresponding upstream IIO event FIFO reset race fix. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, tightening permissions on IIO device nodes such as /dev/iio:device*, disabling or unloading unnecessary IIO drivers where operationally safe, and avoiding passing IIO devices into containers or sandboxes used by untrusted code. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, contains the fix. Validate with uname -a, distribution package metadata, vendor security advisories, and kernel changelogs referencing the IIO event FIFO reset race or CVE-2026-64496. Check whether the system exposes IIO interfaces by reviewing /dev/iio:device* and loaded IIO-related modules. Confirm that untrusted users or containers cannot access IIO device nodes unless explicitly required. After patching and rebooting, verify the active kernel version matches a fixed vendor build. For defense-in-depth validation, confirm device permissions, udev rules, container device passthrough settings, and mandatory access control profiles do not grant unnecessary access to IIO character devices.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as an unprivileged or low-privileged user.
2. Identify that the IIO subsystem and relevant device nodes or ioctl paths are available to the process.
3. Create a multithreaded process that shares the file descriptor table between threads.
4. Trigger creation of an IIO event file descriptor through the IIO event ioctl path.
5. Race another thread to read from the newly installed anonymous event file descriptor before the kernel completes the FIFO reset sequence.
6. Cause inconsistent kfifo indexes so a later read observes an underflowed FIFO length.
7. Read data copied from beyond the intended event FIFO buffer, leaking adjacent kernel memory to user space.
8. Use repeated leaks for sensitive data recovery, kernel address disclosure, or as a primitive for additional local exploitation.

How to detect it

This vulnerability is difficult to confirm after exploitation because successful exploitation may only leak kernel memory to a local process and may not leave a distinct log entry. Focus detection on exposure, suspicious local behavior, and crash artifacts. Review auditd, eBPF telemetry, EDR process telemetry, and shell/process accounting for processes accessing /dev/iio:device* followed by repeated ioctl and read activity, especially from unexpected users, containers, build jobs, or temporary directories. Review kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dumps for oopses, warnings, general protection faults, KASAN reports, or panics involving IIO event handling, kfifo_to_user, iio_event_chrdev_read, or related kfifo functions. If syscall auditing is enabled, look for high-frequency ioctl/read patterns against IIO character devices. Absence of these artifacts does not rule out exploitation; memory disclosure can succeed silently.

• /dev/iio:device
• IIO_GET_EVENT_FD_IOCTL
• iio_event_getfd
• iio_event_chrdev_read
• kfifo_to_user
• kfifo_reset_out
• BUG:
• Oops:
• general protection fault
• KASAN
• kernel panic

What your security team should do

• Inventory Linux systems that expose IIO devices or run kernels with IIO support, prioritizing multi-user, shared compute, embedded, edge, industrial, and workstation environments.
• Patch affected Linux kernels through the appropriate vendor channel and reboot into the fixed kernel.
• Prioritize systems where untrusted users, CI jobs, containers, or third-party workloads can execute local code and access /dev/iio:device* nodes.
• Until patching is complete, restrict permissions on IIO device nodes and remove unnecessary device passthrough into containers or virtualized workloads.
• Monitor for unusual local processes repeatedly opening IIO devices, invoking IIO event ioctls, and performing high-rate reads against anonymous file descriptors.
• Review kernel logs for crashes, warnings, or oops messages involving IIO event handling, kfifo operations, or suspicious local denial-of-service symptoms.
• Because this is not currently KEV-listed and has very low EPSS, handle as important kernel hardening rather than emergency internet-facing exposure, unless local multi-tenant risk is high.