← Back to CVE intelligence
CVE intelligence

CVE-2024-42232

Vulnerability intelligence

Published Aug 7, 2024Sources checked Nov 11, 2026
5.5MEDIUMCVSS out of 10
What this means

Review the available evidence

CVE-2024-42232 and is rated Medium severity with a CVSS score of 5.5. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Microsoft Security Response Center guidance

Vendor revision: Aug 12, 2026

CBL-Mariner Releases

Vendor-listed releases

  • 5.15.164.1-1
  • 6.6.43.1-7
CISA KEVNot listedBased on the latest collected catalog
EPSS0.8%Estimated 30-day exploitation probability
Ransomware useNot markedCISA KEV ransomware field
Threat actors0Source-linked actor relationships
Overview

What is CVE-2024-42232?

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

Source: NVD