linux-kernel - Re: [PATCH] bpf: restrict verifier access to bpf_lru

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

Message-ID: <27c7c76c-becf-47b1-812b-05f260a8cd85@linux.dev>
Date: Tue, 15 Jul 2025 14:26:56 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>,
 Shankari Anand <shankari.ak0208@...il.com>
Cc: bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 Martin KaFai Lau <martin.lau@...nel.org>, Alexei Starovoitov
 <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
 Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
 syzbot+ad4661d6ca888ce7fe11@...kaller.appspotmail.com
Subject: Re: [PATCH] bpf: restrict verifier access to bpf_lru_node.ref

On 7/15/25 7:49 AM, Alexei Starovoitov wrote:
> Also you misread the kcsan report.
> 
> It says that 'read' comes from:
> 
> read to 0xffff888118f3d568 of 4 bytes by task 4719 on cpu 1:
>   lookup_nulls_elem_raw kernel/bpf/hashtab.c:643 [inline]
> 
> which is reading hash and key of htab_elem while
> write side actually writes hash too:
> *(u32 *)((void *)node + lru->hash_offset) = hash;
> 
> Martin,
> is it really possible for these read/write to race ?

I think it is possible. The elem in the lru's freelist currently does not wait 
for a rcu gp before reuse. There is a chance that the rcu reader is still 
reading the hash value that was put in the freelist, while the writer is reusing 
and updating it.

I think the percpu_freelist used in the regular hashmap should have similar 
behavior, so may be worth finding a common solution, such as waiting for a rcu 
gp before reusing it.