"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Defer work in bpf_timer_cancel_and_free\n\nCurrently, the same case as previous patch (two timer callbacks trying\nto cancel each other) can be invoked through bpf_map_update_elem as\nwell, or more precisely, freeing map elements containing timers. Since\nthis relies on hrtimer_cancel as well, it is prone to the same deadlock\nsituation as the previous patch.\n\nIt would be sufficient to use hrtimer_try_to_cancel to fix this problem,\nas the timer cannot be enqueued after async_cancel_and_free. Once\nasync_cancel_and_free has been done, the timer must be reinitialized\nbefore it can be armed again. The callback running in parallel trying to\narm the timer will fail, and freeing bpf_hrtimer without waiting is\nsufficient (given kfree_rcu), and bpf_timer_cb will return\nHRTIMER_NORESTART, preventing the timer from being rearmed again.\n\nHowever, there exists a UAF scenario where the callback arms the timer\nbefore entering this function, such that if cancellation fails (due to\ntimer callback invoking this routine, or the target timer callback\nrunning concurrently). In such a case, if the timer expiration is\nsignificantly far in the future, the RCU grace period expiration\nhappening before it will free the bpf_hrtimer state and along with it\nthe struct hrtimer, that is enqueued.\n\nHence, it is clear cancellation needs to occur after\nasync_cancel_and_free, and yet it cannot be done inline due to deadlock\nissues. We thus modify bpf_timer_cancel_and_free to defer work to the\nglobal workqueue, adding a work_struct alongside rcu_head (both used at\n_different_ points of time, so can share space).\n\nUpdate existing code comments to reflect the new state of affairs."
