bpf: Fail bpf_timer_cancel when callback is being cancelled

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

bpf: Fail bpf_timer_cancel when callback is being cancelled

Given a schedule:

timer1 cb timer2 cb

bpf_timer_cancel(timer2); bpf_timer_cancel(timer1);

Both bpf_timer_cancel calls would wait for the other callback to finish

executing, introducing a lockup.

Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps

track of all in-flight cancellation requests for a given BPF timer.

Whenever cancelling a BPF timer, we must check if we have outstanding

cancellation requests, and if so, we must fail the operation with an

error (-EDEADLK) since cancellation is synchronous and waits for the

callback to finish executing. This implies that we can enter a deadlock

situation involving two or more timer callbacks executing in parallel

and attempting to cancel one another.

Note that we avoid incrementing the cancelling counter for the target

timer (the one being cancelled) if bpf_timer_cancel is not invoked from

a callback, to avoid spurious errors. The whole point of detecting

cur->cancelling and returning -EDEADLK is to not enter a busy wait loop

(which may or may not lead to a lockup). This does not apply in case the

caller is in a non-callback context, the other side can continue to

cancel as it sees fit without running into errors.

Background on prior attempts:

Earlier versions of this patch used a bool 'cancelling' bit and used the

following pattern under timer->lock to publish cancellation status.

lock(t->lock);

t->cancelling = true;

mb();

if (cur->cancelling)

return -EDEADLK;

unlock(t->lock);

hrtimer_cancel(t->timer);

t->cancelling = false;

The store outside the critical section could overwrite a parallel

requests t->cancelling assignment to true, to ensure the parallely

executing callback observes its cancellation status.

It would be necessary to clear this cancelling bit once hrtimer_cancel

is done, but lack of serialization introduced races. Another option was

explored where bpf_timer_start would clear the bit when (re)starting the

timer under timer->lock. This would ensure serialized access to the

cancelling bit, but may allow it to be cleared before in-flight

hrtimer_cancel has finished executing, such that lockups can occur

again.

Thus, we choose an atomic counter to keep track of all outstanding

cancellation requests and use it to prevent lockups in case callbacks

attempt to cancel each other while executing in parallel.