CVE-2026-89600

The Linux kernel's fanotify subsystem contains a use-after-free in which a permission event stores a pointer to file-range information living on the triggering task's kernel stack. If a signal interrupts the triggering task while the event reader has marked the event FAN_EVENT_REPORTED and is sleeping to prepare a file descriptor, the task unwinds the stack frame while the reader still owns the event, and the reader then copies the stale stack value (via pevent->ppos) to userspace, as confirmed by a KASAN report in fanotify_read. A local attacker with low privileges who can trigger fanotify permission/pre-content events and win this race could leak kernel stack contents or corrupt memory, with CVSS 3.1 rating this high (7.8) for confidentiality, integrity, and availability impact. Any system running a kernel with this fanotify code path is affected, though triggering it requires local access and use of the fanotify permission-event interface (typically used by file-content inspection, HSM/tiering, or anti-malware software). There is no public proof of concept and no known exploitation in the wild; the issue is fixed upstream by storing the range position directly in the permission event.

What to do: Patch to a kernel release containing the upstream fanotify fix once your distro ships it (the fix stores the range position in the permission event and uses FANOTIFY_NO_RANGE when range info is unavailable). In the meantime, audit and restrict local, untrusted code execution on hosts running fanotify-based content-scanning or tiering agents, and watch kernel logs for KASAN/slab use-after-free reports in fanotify_read as an indicator of attempted triggering.