UBUNTU-CVE-2026-99175: Medium severity ubuntu/linux-azure vulnerability
In the Linux kernel, the following vulnerability has been resolved: fsnotify: prevent mark additions during connector teardown fsnotifydestroymarks() 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 INIGNORED 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 markslist 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 inotifyshowfdinfo+0x1dc/0x5e0 seqshow+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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
During connector teardown, set a DESTROYING flag under conn->lock before walking marks, reject new marks on that connector with -ENOENT, and do not wait for teardown while holding the group mutex.
Event History
Frequently Asked Questions
What conditions are needed to trigger this issue?
The issue requires a race between fsnotify connector teardown and adding an inotify watch. The described crash occurs when an unprivileged fdinfo read races the final connector detach after a replacement watch has been added.
Can an unprivileged local user be affected?
Yes. The description specifically identifies an unprivileged fdinfo read as capable of reaching the null-pointer dereference when it races the final detach.
What is the observable impact?
The reported outcome is a KASAN-detected null-pointer dereference in igrab(NULL), reached through inotify_show_fdinfo. This can cause a kernel BUG during the race.
Which Ubuntu kernel packages are listed as affected?
The listed software includes ubuntu/linux, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-oracle, ubuntu/linux-aws-fips, ubuntu/linux-azure-fips, ubuntu/linux-fips, and ubuntu/linux-gcp-fips.