CVE-2024-41045

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Defer work in bpf_timer_cancel_and_free<br /> <br /> Currently, the same case as previous patch (two timer callbacks trying<br /> to cancel each other) can be invoked through bpf_map_update_elem as<br /> well, or more precisely, freeing map elements containing timers. Since<br /> this relies on hrtimer_cancel as well, it is prone to the same deadlock<br /> situation as the previous patch.<br /> <br /> It would be sufficient to use hrtimer_try_to_cancel to fix this problem,<br /> as the timer cannot be enqueued after async_cancel_and_free. Once<br /> async_cancel_and_free has been done, the timer must be reinitialized<br /> before it can be armed again. The callback running in parallel trying to<br /> arm the timer will fail, and freeing bpf_hrtimer without waiting is<br /> sufficient (given kfree_rcu), and bpf_timer_cb will return<br /> HRTIMER_NORESTART, preventing the timer from being rearmed again.<br /> <br /> However, there exists a UAF scenario where the callback arms the timer<br /> before entering this function, such that if cancellation fails (due to<br /> timer callback invoking this routine, or the target timer callback<br /> running concurrently). In such a case, if the timer expiration is<br /> significantly far in the future, the RCU grace period expiration<br /> happening before it will free the bpf_hrtimer state and along with it<br /> the struct hrtimer, that is enqueued.<br /> <br /> Hence, it is clear cancellation needs to occur after<br /> async_cancel_and_free, and yet it cannot be done inline due to deadlock<br /> issues. We thus modify bpf_timer_cancel_and_free to defer work to the<br /> global workqueue, adding a work_struct alongside rcu_head (both used at<br /> _different_ points of time, so can share space).<br /> <br /> Update existing code comments to reflect the new state of affairs.