netdev - Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e37c0a65-a3f6-e2e6-c2ad-367db20253a0@meta.com>
Date: Tue, 16 May 2023 10:08:17 -0700
From: Yonghong Song <yhs@...a.com>
To: starmiku1207184332@...il.com, ast@...nel.org, daniel@...earbox.net,
        john.fastabend@...il.com, andrii@...nel.org, martin.lau@...ux.dev,
        song@...nel.org, yhs@...com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, davem@...emloft.net,
        kuba@...nel.org, hawk@...nel.org
Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in
 __bpf_prog_put()



On 5/16/23 4:18 AM, starmiku1207184332@...il.com wrote:
> From: Teng Qi <starmiku1207184332@...il.com>
> 
> 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@...il.com>