Lucene search

K
ubuntucveUbuntu.comUB:CVE-2024-42232
HistoryAug 07, 2024 - 12:00 a.m.

CVE-2024-42232

2024-08-0700:00:00
ubuntu.com
ubuntu.com
3
linux kernel
libceph
vulnerability
race condition
delayed work
use-after-free

CVSS3

5.5

Attack Vector

LOCAL

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

AI Score

7.1

Confidence

High

EPSS

0

Percentile

5.0%

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

CVSS3

5.5

Attack Vector

LOCAL

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

AI Score

7.1

Confidence

High

EPSS

0

Percentile

5.0%