CVE-2026-89600 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
fanotify: fix use-after-free of file range info
fsnotify_pre_content() builds its file_range on the triggering task's stack. fanotify_alloc_perm_event() saves a pointer to range.pos in the heap-allocated permission event so copy_range_info_to_user() can report the offset later.
The event reader can set the event state to FAN_EVENT_REPORTED and then sleep while preparing the file descriptor. If a signal interrupts the triggering task at that point, fanotify_get_response() changes the state to FAN_EVENT_CANCELED and returns. This unwinds the file_range stack frame while the reader still owns the event. The reader then dereferences pevent->ppos and copies the stale stack value to userspace.
KASAN reported:
BUG: KASAN: use-after-free in fanotify_read+0x293e/0x2970 Read of size 8 at addr ffff88811434fc50 by task fanotify_inotif/95 Call Trace: fanotify_read+0x293e/0x2970 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Store the range position directly in the permission event and use FANOTIFY_NO_RANGE when range information is unavailable. The event remains alive until the reader finishes, so the reported offset no longer depends on the triggering task's stack.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified as a use-after-free flaw within the Linux kernel’s fanotify subsystem stems from an improper handling of memory lifecycles during asynchronous permission events. Specifically, the function fsnotify_pre_content allocates its file_range structure on the stack frame of the task that triggered the filesystem notification. Subsequently, fanotify_alloc_perm_event captures a pointer to the range.pos member and stores it within a heap-allocated permission event object. This design assumes that the triggering task’s stack remains valid for as long as the permission event exists in memory. However, this assumption is violated under specific race conditions involving signal handling and state transitions between the kernel space and user space readers of fanotify events.
The operational impact arises when an application reads a fanotify event and sets its state to FAN_EVENT_REPORTED before sleeping while preparing file descriptors for response delivery. If the original triggering task receives a signal during this interval, the function fanotify_get_response is invoked, which changes the event state to FAN_EVENT_CANCELED and returns control immediately. This return causes the unwinding of the stack frame where the file_range structure resides, effectively freeing that memory region from the perspective of the kernel’s allocation tracking. Despite the triggering task’s context being destroyed or modified, the heap-allocated permission event still holds a dangling pointer to the now-invalid range.pos location on the previous stack.
When the user-space reader eventually attempts to process this canceled event and copy the file offset information via copy_range_info_to_user, it dereferences the stale pointer pevent->ppos. This action results in reading from freed memory, which constitutes a classic use-after-free vulnerability. As evidenced by Kernel Address Sanitizer reports, this leads to reads of size eight bytes at arbitrary addresses determined by prior stack usage patterns. Such an exploit could potentially allow an attacker to leak kernel stack contents, leading to information disclosure vulnerabilities that may aid in further exploitation techniques such as return-oriented programming or bypassing address space layout randomization protections.
From a classification perspective, this flaw aligns with CWE-416, Use After Free, where memory is accessed after it has been freed, and potentially CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, due to the race condition between signal handling in one task and event processing in another. In terms of ATT&CK mapping, this vulnerability facilitates Initial Access or Defense Evasion through information leakage techniques like T1082 System Information Discovery, as it allows reading kernel memory that should not be accessible to unprivileged user-space processes.
The resolution involves restructuring how file range data is managed within the fanotify permission event lifecycle. Instead of storing a pointer to stack-allocated data, the fix mandates storing the actual value of the range position directly within the heap-allocated permission event structure. This ensures that the offset information remains valid regardless of whether the triggering task’s stack frame has been unwound or modified by signal handling. Additionally, when range information is unavailable or cannot be safely captured, the system utilizes FANOTIFY_NO_RANGE to indicate this state explicitly rather than relying on potentially invalid pointers.
This mitigation strategy eliminates the dependency on the transient lifetime of the triggering task’s stack for data that must persist until user-space consumption completes. By decoupling the storage of metadata from the execution context of the event generator, the kernel prevents the use-after-free condition entirely. System administrators and developers should ensure that kernels are updated to include this patch to maintain system integrity and prevent potential information disclosure attacks derived from fanotify subsystem interactions. Regular auditing of signal handling paths in asynchronous notification systems remains critical for maintaining robust security postures against similar concurrency-related memory safety issues.