On 5/16/23 4:18 AM, starmiku1207184332@xxxxxxxxx wrote:
From: Teng Qi <starmiku1207184332@xxxxxxxxx>
Hi, bpf developers,
We are developing a static tool to check the matching between helpers and the
context of hooks. During our analysis, we have discovered some important
findings that we would like to report.
‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that function
bpf_prog_put_deferred() won`t be called in the condition of
‘in_irq() || irqs_disabled()’.
if (in_irq() || irqs_disabled()) {
INIT_WORK(&aux->work, bpf_prog_put_deferred);
schedule_work(&aux->work);
} else {
bpf_prog_put_deferred(&aux->work);
}
We suspect this condition exists because there might be sleepable operations
in the callees of the bpf_prog_put_deferred() function:
kernel/bpf/syscall.c: 2097 __bpf_prog_put()
kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred()
kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref()
kvfree(prog->aux->jited_linfo);
kvfree(prog->aux->linfo);
Looks like you only have suspicion here. Could you find a real violation
here where __bpf_prog_put() is called with !in_irq() &&
!irqs_disabled(), but inside spin_lock or rcu read lock? I have not seen
things like that.
Additionally, we found that array prog->aux->jited_linfo is initialized in
‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’:
prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo,
sizeof(*prog->aux->jited_linfo), bpf_memcg_flags(GFP_KERNEL | __GFP_NOWARN));
Any problem here?
Our question is whether the condition 'in_irq() || irqs_disabled() == false' is
sufficient for calling 'kvfree'. We are aware that calling 'kvfree' within the
context of a spin lock or an RCU lock is unsafe.
Therefore, we propose modifying the condition to include in_atomic(). Could we
update the condition as follows: "in_irq() || irqs_disabled() || in_atomic()"?
Thank you! We look forward to your feedback.
Signed-off-by: Teng Qi <starmiku1207184332@xxxxxxxxx>
