Bug 1228531 (CVE-2024-41045)

Summary:	VUL-0: CVE-2024-41045: kernel: bpf: Defer work in bpf_timer_cancel_and_free
Product:	[Novell Products] SUSE Security Incidents	Reporter:	SMASH SMASH <smash_bz>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	IN_PROGRESS ---	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	andrea.mattiazzo, security-team, shung-hsi.yu
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://smash.suse.de/issue/415437/
See Also:	https://bugzilla.suse.com/show_bug.cgi?id=1222557
Whiteboard:	CVSSv3.1:SUSE:CVE-2024-41045:6.4:(AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Found By:	Security Response Team	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:
Bug Blocks:	1228534

Description SMASH SMASH 2024-07-30 10:02:29 UTC

In the Linux kernel, the following vulnerability has been resolved:

bpf: Defer work in bpf_timer_cancel_and_free

Currently, the same case as previous patch (two timer callbacks trying
to cancel each other) can be invoked through bpf_map_update_elem as
well, or more precisely, freeing map elements containing timers. Since
this relies on hrtimer_cancel as well, it is prone to the same deadlock
situation as the previous patch.

It would be sufficient to use hrtimer_try_to_cancel to fix this problem,
as the timer cannot be enqueued after async_cancel_and_free. Once
async_cancel_and_free has been done, the timer must be reinitialized
before it can be armed again. The callback running in parallel trying to
arm the timer will fail, and freeing bpf_hrtimer without waiting is
sufficient (given kfree_rcu), and bpf_timer_cb will return
HRTIMER_NORESTART, preventing the timer from being rearmed again.

However, there exists a UAF scenario where the callback arms the timer
before entering this function, such that if cancellation fails (due to
timer callback invoking this routine, or the target timer callback
running concurrently). In such a case, if the timer expiration is
significantly far in the future, the RCU grace period expiration
happening before it will free the bpf_hrtimer state and along with it
the struct hrtimer, that is enqueued.

Hence, it is clear cancellation needs to occur after
async_cancel_and_free, and yet it cannot be done inline due to deadlock
issues. We thus modify bpf_timer_cancel_and_free to defer work to the
global workqueue, adding a work_struct alongside rcu_head (both used at
_different_ points of time, so can share space).

Update existing code comments to reflect the new state of affairs.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-41045
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-41045.mbox
https://git.kernel.org/stable/c/7aa5a19279c3639ae8b758b63f05d0c616a39fa1
https://git.kernel.org/stable/c/a6fcd19d7eac1335eb76bc16b6a66b7f574d1d69
https://www.cve.org/CVERecord?id=CVE-2024-41045

Comment 3 Shung-Hsi Yu 2024-08-08 06:29:52 UTC

Fixing commit d4523831f07a "bpf: Fail bpf_timer_cancel when callback is being
cancelled" backported to the following branches (alone with other commits):

- SLE15-SP6 (HEAD a65dc5b6090, opted to pull in refactoring patch 2-5,
  selftest dependency patch 8-9. Patch 6 is the actual fix and patch 10 is the
  associated selftest)
  1.  fd381ce60a2d "bpf: Check map->usercnt after timer->timer is assigned"
  2.  be2749beff62 "bpf: make timer data struct more generic"
  3.  56b4a177ae63 "bpf: replace bpf_timer_init with a generic helper"
  4.  073f11b02643 "bpf: replace bpf_timer_set_callback with a generic helper"
  5.  fc22d9495f0b "bpf: replace bpf_timer_cancel_and_free with a generic
      helper"
  6.  d4523831f07a "bpf: Fail bpf_timer_cancel when callback is being
      cancelled"
  7.  a6fcd19d7eac "bpf: Defer work in bpf_timer_cancel_and_free"
  8.  d6247ecb6c1e "bpf: Add ability to pin bpf timer to calling CPU"
  9.  0d7ae0686075 "selftests/bpf: Test pinning bpf timer to a core"
  10. 50bd5a0c658d "selftests/bpf: Add timer lockup selftest"

- SLE15-SP5 (HEAD 13bca1520cc6, opted for the least intrusive change)
  1.  fd381ce60a2d "bpf: Check map->usercnt after timer->timer is assigned"
      (technically independent of the next two here, but it is a fix for the
      same buggy commit)
  2.  d4523831f07a "bpf: Fail bpf_timer_cancel when callback is being
      cancelled"
  3.  a6fcd19d7eac "bpf: Defer work in bpf_timer_cancel_and_free"

Reassigning back to security team.