CVE-2024-42232
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk13th percentile - higher than 13% of all known CVEs
Summary
In the Linux kernel, a race condition was found in libceph between delayed_work() and ceph_monc_stop(). The handling of delayed work in ceph_monc_stop() is prone to races with mon_fault() and finish_hunting(), which can requeue the delayed work after it was canceled, potentially leading to use-after-free on the monc structure and associated objects.
Risk Assessment
Use-after-free can lead to system crashes or potentially privilege escalation if an attacker can exploit the bug to gain control of the kernel.
Recommendation
It is recommended to update the Linux kernel to a version containing the fix for CVE-2024-42232, which eliminates the race and prevents use-after-free.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed