CVE-2026-89990: ceph: lock mutex in ceph_mds_check_access()
In the Linux kernel, the following vulnerability has been resolved:
ceph: lock mutex in cephmdscheckaccess()
MDS session OPEN handling replaces mdsc->scapauths under mdsc->mutex, freeing the previous array and its strings.
cephmdscheckaccess() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this:
Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : cephmdscheckaccess+0xd4/0x550 lr : cephmdscheckaccess+0xc8/0x550 [...] Call trace: cephmdscheckaccess+0xd4/0x550 (P) cephatomicopen+0x138/0xbe8 pathopenat+0xa24/0xfa8 dofilpopen+0x94/0x158 dosysopenat2+0x88/0xf8
Affected Software
Event History
Frequently Asked Questions
What condition triggers the race?
The race requires ceph_mds_check_access() to inspect the MDS capability-authority array while concurrent MDS session OPEN handling replaces and frees the previous array under mdsc->mutex. This can cause access to freed memory during a Ceph filesystem access check.
How might an affected system present?
The reported failure mode is a kernel paging request and Oops with ceph_mds_check_access() in the call trace. The example occurred during a php-cgi process opening a file, with ceph_atomic_open(), path_openat(), and do_filp_open() also present in the trace.
What is the immediate technical remediation indicated by the fix?
The resolved issue is addressed by locking the mutex in ceph_mds_check_access() while it traverses the capability-authority array. The provided references point to stable kernel commits containing the fix.