Look up another CVE · open CVE-2026-89600 in the interactive tracker
CVE-2026-89600
fanotify: fix use-after-free of file range info
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem fs/notify. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89600 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/notify/fanotify/fanotify.c
fs/notify/fanotify/fanotify.h
fs/notify/fanotify/fanotify_user.c
- What this is
- FANOTIFYMAINTAINERS section matched on fs/notify/fanotify/ · linux-fsdevel@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_FANOTIFY /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_FANOTIFY
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/notify
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.50 | 66aa9a9e6481 |
| 6.14 | 7.2.4 | b8f73b163b64 |
| 6.14 | 7.3 | d7f1cf5be33e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached only through local syscalls: fanotify_init/fanotify_mark to install a FAN_CLASS_PRE_CONTENT watch, read() on the fanotify fd, and a local read/write/mmap/truncate of a watched regular file that hits fsnotify_pre_content(). No network protocol handler delivers these events to an attacker.
- AC:LAttack complexity, low
- The attacker owns both sides of the race: a listener that sets FAN_EVENT_REPORTED then sleeps in create_fd() or copy_to_user, and a triggering task they SIGKILL while it waits in fanotify_get_response(). That cancels the wait, unwinds the file_range stack, and leaves pevent->ppos dangling for the reader.
- PR:LPrivileges required, low
- FAN_CLASS_PRE_CONTENT requires capable(CAP_SYS_ADMIN), which a user-namespace root obtains via unshare. Inode FAN_PRE_ACCESS marks do not require init-namespace root; FANOTIFY_UNPRIV only suppresses event fds/pids and does not block permission events or the copy_range_info_to_user() UAF.
- UI:NUser interaction, none
- The attacker creates the watch, triggers pre-content access on their own file, and reads the fanotify fd themselves. No other user must open, mount, or otherwise interact with the system.
- S:UScope, unchanged
- The use-after-free and its impact stay inside the host kernel. This is a same-authority memory-safety issue, not a VM escape, IOMMU bypass, or other cross-boundary sandbox breakout.
- C:HConfidentiality impact, high
- copy_range_info_to_user() dereferences the dangling pevent->ppos and copies eight bytes of the triggering task's freed kernel stack to userspace. After that task exits, the stack can be reused, so the UAF read discloses kernel pointers or other object contents.
- I:HIntegrity impact, high
- This is a kernel use-after-free of stack memory retained via a heap permission event. After the triggering task is killed, the freed stack can be reallocated while the dangling pointer remains, which is a UAF memory-corruption primitive usable for write/control-flow hijack.
- A:HAvailability impact, high
- KASAN already reports a use-after-free in fanotify_read(). If the triggering task exits and its vmap kernel stack is unmapped before the listener loads *ppos, the kernel takes a fault/oops and the system crashes.