CVE-2024-41045

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

bpf: Defer work in bpftimercancelandfree

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

It would be sufficient to use hrtimertrytocancel to fix this problem, as the timer cannot be enqueued after asynccancelandfree. Once asynccancelandfree 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 bpfhrtimer without waiting is sufficient (given kfreercu), and bpftimercb will return HRTIMERNORESTART, 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 asynccancelandfree, and yet it cannot be done inline due to deadlock issues. We thus modify bpftimercancelandfree to defer work to the global workqueue, adding a workstruct alongside rcuhead (both used at _different points of time, so can share space).

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