cbcvebase.
CVE-2024-42239
published 2024-08-07

CVE-2024-42239: In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.17%
6.2th percentile
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_ti

Affected

15 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.9.10-1 (forky)linux 6.9.10-1 (forky)
linuxlinux
linuxlinux>= b00628b1c7d595ae5b544e059c27b1f5828314b4 < 9369830518688ecd5b08ffc08ab3302ce2b5d0f79369830518688ecd5b08ffc08ab3302ce2b5d0f7
linuxlinux>= b00628b1c7d595ae5b544e059c27b1f5828314b4 < 3e4e8178a8666c56813bd167b848fca0f4c9af0a3e4e8178a8666c56813bd167b848fca0f4c9af0a
linuxlinux>= b00628b1c7d595ae5b544e059c27b1f5828314b4 < d4523831f07a267a943f0dde844bf8ead7495f13d4523831f07a267a943f0dde844bf8ead7495f13
linuxlinux_kernel>= 0 < 6.9.10-16.9.10-1
linuxlinux_kernel>= 0 < 6.9.10-16.9.10-1
linuxlinux_kernel>= 0 < 6.8.0-48.486.8.0-48.48
linuxlinux_kernel>= 5.15 < 6.6.416.6.41
linuxlinux_kernel>= 6.7 < 6.9.106.9.10
msrcazl3_kernel_6.6.35.1-5_on_azure_linux_3.0
msrcazl3_kernel_6.6.43.1-7_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
vendor_ubuntu5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.