SEPTEMBER 14, 2026
Live Feed
Back to database
Case File

CVE-2026-89600

HIGH · CVSS 7.8 EPSS 0.12%

Source: NVD + CISA KEV + EPSS · Published 2026-09-11 · Last synced 2026-09-14

CyberRota Analysis

AI-Generated

The vulnerability affects the Linux kernel's fanotify subsystem, where a use-after-free condition can occur due to improper handling of file range information during event processing. This flaw allows an event reader to dereference a stale pointer, potentially leading to arbitrary memory access and exploitation. System administrators and developers using affected Linux kernel versions should prioritize patching this vulnerability to mitigate risks associated with memory corruption and potential system compromise.

CVE
CVE-2026-89600
Severity
HIGH
CVSS
7.8
EPSS
0.12%
Linux

Original NVD Description

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.