CVE-2024-26737

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel<br /> <br /> The following race is possible between bpf_timer_cancel_and_free<br /> and bpf_timer_cancel. It will lead a UAF on the timer-&gt;timer.<br /> <br /> bpf_timer_cancel();<br /> spin_lock();<br /> t = timer-&gt;time;<br /> spin_unlock();<br /> <br /> bpf_timer_cancel_and_free();<br /> spin_lock();<br /> t = timer-&gt;timer;<br /> timer-&gt;timer = NULL;<br /> spin_unlock();<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> kfree(t);<br /> <br /> /* UAF on t */<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> <br /> In bpf_timer_cancel_and_free, this patch frees the timer-&gt;timer<br /> after a rcu grace period. This requires a rcu_head addition<br /> to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,<br /> this does not need a kfree_rcu because it is still under the<br /> spin_lock and timer-&gt;timer has not been visible by others yet.<br /> <br /> In bpf_timer_cancel, rcu_read_lock() is added because this helper<br /> can be used in a non rcu critical section context (e.g. from<br /> a sleepable bpf prog). Other timer-&gt;timer usages in helpers.c<br /> have been audited, bpf_timer_cancel() is the only place where<br /> timer-&gt;timer is used outside of the spin_lock.<br /> <br /> Another solution considered is to mark a t-&gt;flag in bpf_timer_cancel<br /> and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free,<br /> it busy waits for the flag to be cleared before kfree(t). This patch<br /> goes with a straight forward solution and frees timer-&gt;timer after<br /> a rcu grace period.