netdev - [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-next>] [day] [month] [year] [list]

Message-Id: <20230516111823.2103536-1-starmiku1207184332@gmail.com>
Date: Tue, 16 May 2023 11:18:23 +0000
From: starmiku1207184332@...il.com
To: 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,
	Teng Qi <starmiku1207184332@...il.com>
Subject: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()

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);

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));

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>