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: <2a351923-5918-4735-8072-f21379e598c4@linux.dev>
Date: Wed, 28 Jan 2026 23:22:49 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: Kumar Kartikeya Dwivedi <memxor@...il.com>
Cc: bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, 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>,
 Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, kernel-patches-bot@...com
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Disallow BPF_F_LOCK with mixed
 special fields and centralize flag checks



On 2026/1/28 10:27, Kumar Kartikeya Dwivedi wrote:
> On Fri, 23 Jan 2026 at 06:58, Leon Hwang <leon.hwang@...ux.dev> wrote:
>>
>> Disallow combining BPF_F_LOCK with map values that contain special BTF
>> fields other than bpf_spin_lock (e.g. kptr or uptr). Such mixing may lead
>> to subtle or undefined behavior in map value handling. Reject these
>> combinations early by returning -EOPNOTSUPP.
> 
> The commit log is really suboptimal in giving context on why you're doing this.
> You should summarize the discussion from [0], otherwise unless people
> go dig that thread they'd have no clue.
> 
> Also, I would remove the 'undefined behavior' wording. It's just
> semantically different, in that the update doesn't free fields,
> but there's no undefined behavior.
> 
>   [0]: https://lore.kernel.org/bpf/CAADnVQLib8ebe8cmGRj98YZiArendX8u=dSKNUrUFz6NGq7LRg@mail.gmail.com
> 

Agreed.

The commit message needs more context. I'll summarize the prior
discussion and clearly explain why the BPF_F_LOCK + special-field
combination is being disallowed, without using “undefined behavior” wording.

> Please also increase test coverage for other maps in patch 2. Even if
> covering all local storages is not practical, we can definitely do
> task local storage.
> 
Ack.

I'll add a test to cover the change of task local storage.

Thanks,
Leon

[...]


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ