CVE-2026-99175

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's file-change monitoring code can make the whole system crash when certain file watches are added and removed at the same time.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Race condition in fsnotify_destroy_marks allows concurrent mark insertion during connector teardown, bypassing group mutex protections and enabling igrab(NULL) leading to null pointer dereference.

Why it matters to the business

Kernel crashes on Linux systems using inotify or similar fsnotify backends can cause denial of service, unplanned downtime, and potential loss of in-flight operations.

How an attack unfolds

Local attacker adds and re-adds an inotify watch to trigger insertion during fsnotify connector teardown; the walk misses the replacement, detaches the connector, and a concurrent fdinfo read then dereferences a null object pointer.

How to fix it

Apply the upstream fsnotify fix that sets a DESTROYING flag under conn->lock before teardown and rejects new marks with -ENOENT; rebuild and reboot to the patched kernel.

How to confirm the fix worked

Confirm the kernel source contains the DESTROYING flag logic and the -ENOENT rejection path; reproduce the original fdinfo race and verify no KASAN null-ptr-deref occurs.

Typical attack path

Obtain local unprivileged access on affected Linux kernel
Create and re-add inotify watch on a watched object to race mark insertion
Force fsnotify_destroy_marks on the connector while holding no group mutex
Trigger seq_show / inotify_show_fdinfo to reach igrab on the detached null object

How to detect it

Search kernel logs and dmesg for KASAN reports citing igrab and inotify_show_fdinfo; correlate with processes performing fdinfo reads or inotify operations around the crash time.

BUG: KASAN: null-ptr-deref in igrab+0x24/0x100
inotify_show_fdinfo+0x1dc/0x5e0
seq_show+0x397/0x690
Write of size 4 at addr 0000000000000148

What your security team should do

Expedite deployment of patched kernels to all multi-user and container hosts
Add kernel oops and KASAN alerts to monitoring for fsnotify-related crashes
Review any local tooling that performs frequent inotify add/remove operations

The record

In the Linux kernel, the following vulnerability has been resolved: fsnotify: prevent mark additions during connector teardown fsnotify_destroy_marks() keeps a reference to its current mark while it drops conn->lock to destroy the mark. This stabilizes the forward-walk cursor, but does not prevent a new mark from being inserted before it. For example, an inotify watch re-added after IN_IGNORED sorts before the old, detached mark for the same group. The walk can miss the replacement and then detach the entire connector from the object. The replacement is still on its group's marks_list and, for inotify, in the watch IDR. The group mutex no longer protects the connector's object from disappearing. An unprivileged fdinfo read racing the final detach can consequently call igrab(NULL): BUG: KASAN: null-ptr-deref in igrab+0x24/0x100 Write of size 4 at addr 0000000000000148 Call Trace: igrab+0x24/0x100 inotify_show_fdinfo+0x1dc/0x5e0 seq_show+0x397/0x690 Set a DESTROYING flag under conn->lock before starting the walk, and reject new marks on that connector with -ENOENT. The existing add-mark error paths undo the temporary group-list entry and the backend's watch allocation. Do not wait for teardown while holding the group mutex, which the destroyer needs. Once the old connector is detached, an add can install a fresh connector as before. This closes the insertion race for all object types using the common connector teardown, without changing the mark reference or SRCU lifetime rules.

Affected packages

Ecosystem	Package	Introduced	Fixed