CVE-2026-89600

What it actually does

This is a Linux kernel use-after-free in the fanotify permission-event path. fsnotify_pre_content() builds file-range state on the triggering task's stack, and fanotify_alloc_perm_event() previously saved a pointer to that stack-backed range position in a heap-allocated permission event for later copy_range_info_to_user(). If the event reader marks the event FAN_EVENT_REPORTED and sleeps while preparing a file descriptor, a signal can cancel the event (FAN_EVENT_CANCELED), unwind the stack frame, and leave the reader holding a dangling pevent->ppos. fanotify_read then dereferences freed stack memory (KASAN: 8-byte read in fanotify_read) and copies stale kernel stack contents to userspace. The defect is a kernel memory-safety issue: immediate impact is an out-of-lifetime read/info leak of stack data; as with other local kernel UAFs, it is scored as high confidentiality, integrity, and availability impact (CVSS 7.8, AV:L/AC:L/PR:L/UI:N).

Why it matters to the business

A local, low-privilege user or process that can exercise fanotify permission events may crash the host or, in a worst-case conversion of a kernel UAF, elevate privileges and fully compromise the machine. Shared Linux servers, developer workstations, CI runners, and multi-tenant or container hosts where untrusted local code can run are the primary operational concern. The issue is not in CISA KEV, has no reported ransomware use, exploit maturity is None, EPSS is low and flat (~0.00124 over 30 days), and it has been public for about 37 days without named threat-actor activity—so mass remote compromise is unlikely, but kernel memory-safety fixes should still be treated as a standard high-priority patch on any host that exposes fanotify to untrusted local users.

How an attack unfolds

Public details describe a local race, not a remote worm. An already-local attacker would need to use fanotify permission events so the kernel allocates an event that (before the fix) pointed at stack-resident file-range info. The attacker would then try to desynchronize the event reader (which can sleep after marking the event reported) from the triggering task, using a signal so fanotify_get_response() cancels the event and tears down the stack frame while the reader still owns the object. The reader’s subsequent copy of pevent->ppos to userspace yields leftover kernel stack data. There is no public exploit, no KEV listing, and no attributed APT or ransomware campaign. Weaponization beyond information leak would require additional, unpublished memory-corruption work and is not known to be in the wild.

How to fix it

Apply Linux kernel updates from your distribution or vendor that include the fanotify fix: store the file-range position inside the permission event itself and use FANOTIFY_NO_RANGE when range information is unavailable, so the reported offset no longer depends on the triggering task’s stack. The event then remains valid until the reader finishes. No specific upstream or distro package versions were supplied with this record—track kernel changelogs and vendor advisories for the fanotify use-after-free of file range info and deploy the patched kernel, then reboot so the running image matches. If you cannot patch immediately, restrict untrusted local users and containers from using fanotify permission events (capabilities, seccomp, LSM policy) and avoid exposing that API to untrusted workloads. Do not attempt untested kernel live-patches unless your vendor ships one for this fix.

How to confirm the fix worked

Confirm the running kernel (uname -r and distro package changelog) includes the fanotify change that embeds range position in the permission event and introduces FANOTIFY_NO_RANGE when range info is unavailable. Search vendor/kernel git history or package notes for the commit message “fanotify: fix use-after-free of file range info.” After reboot, verify the new kernel is actually running and that KASAN or kernel warning paths no longer report use-after-free in fanotify_read. On hosts that still need fanotify, regression-test permission-event consumers (mark reported, handle signals on the triggering task) in a lab—not production—to ensure range offsets are reported without kernel faults. Inventory systems where unprivileged processes can open fanotify groups as remaining exposure if the kernel is unpatched.

Typical attack path

1. Obtain local (non-remote) execution as an unprivileged user or process on an unpatched Linux host.
2. Use fanotify permission-event interfaces so the kernel creates a permission event that historically stored a pointer into the triggering task’s stack-backed file-range info.
3. Cause the event consumer to pause after the event is marked reported while a signal interrupts the triggering task, canceling the event and freeing the stack frame.
4. Trigger fanotify_read to dereference the dangling range pointer and copy stale kernel stack data to userspace.
5. Optionally attempt further local privilege abuse if the memory-safety condition can be turned into broader kernel corruption; no public, reliable method is documented.

How to detect it

This is a local kernel race with no known public exploit or named threat actors, so look for crash/forensic artifacts rather than a distinctive malware implant. Review kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent), kdump/vmcore, and KASAN/KUBSAN reports for use-after-free or invalid reads attributed to fanotify_read, vfs_read, or ksys_read on tasks interacting with fanotify. Hunt for unexpected fanotify group creation or permission-event listeners from unprivileged users around the time of a kernel oops. Because the UAF copies stale stack data to userspace, there may be no durable file IOC if the host did not crash. Correlate with process accounting/audit of fanotify-related syscalls if audit rules exist. Absence of these signs does not prove the bug was never hit—only that it did not leave a crash trace.

• BUG: KASAN: use-after-free in fanotify_read
• use-after-free in fanotify_read
• Read of size 8 at addr
• fanotify_read+
• vfs_read+
• ksys_read+
• do_syscall_64+
• task fanotify
• FAN_EVENT_CANCELED
• FAN_EVENT_REPORTED

What your security team should do

• Patch and reboot Linux kernels to a build that includes the fanotify file-range UAF fix; treat this as a normal high-severity local kernel update, not an emergency KEV outage.
• Prioritize multi-tenant, container, CI, and developer hosts where untrusted local code can exercise fanotify; internet-only edge boxes with no local untrusted users are lower urgency.
• Until patched, limit FANOTIFY / permission-event use by untrusted users via capabilities, seccomp, and LSM policy.
• Watch kernel logs and KASAN/kdump for fanotify_read use-after-free traces; there is no evidence of in-the-wild or ransomware exploitation (EPSS ~0.00124, exploit maturity None).
• Track distro advisories for exact package versions; this record does not list fixed versions.
• Do not invest in custom exploit development or PoCs; use vendor patches and defensive controls only.