netdev - Re: [PATCH bpf-next v1 1/2] bpf,ktls: Fix data corruption when using bpf_msg_pop

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: <20250605145529.3q3aqr6iygpa6xg6@gmail.com>
Date: Thu, 5 Jun 2025 07:55:29 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: Cong Wang <xiyou.wangcong@...il.com>, bpf@...r.kernel.org,
	Boris Pismenny <borisp@...dia.com>,
	Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	Eduard Zingerman <eddyz87@...il.com>,
	Mykola Lysenko <mykolal@...com>,
	Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Martin KaFai Lau <martin.lau@...ux.dev>, 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>, Ihor Solodrai <isolodrai@...a.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH bpf-next v1 1/2] bpf,ktls: Fix data corruption when using
 bpf_msg_pop_data() in ktls

On 2025-06-02 11:04:50, Jiayuan Chen wrote:
> 2025/5/30 02:16, "Cong Wang" <xiyou.wangcong@...il.com> 写到:
> 
> > 
> > On Fri, May 23, 2025 at 09:18:58PM +0800, Jiayuan Chen wrote:
> > 

[...]

> > 
> > I am wondering if we need to WARN here? Because the code below this
> > 
> > handles it gracefully:
> > 
> 
> Hi Cong
> 
> The ctx->open_rec is freed after a TLS record is processed (regardless
> of whether the redirect check passes or triggers a redirect).
> The 'if (rec)' check in the subsequent code you print is indeed designed
> to handle the expected lifecycle state of open_rec.
> 
> But the code path I modified should never see a NULL open_rec under normal
> operation As this is a bug fix, I need to ensure the fix itself doesn't
> create new issues. 
> 
> Thanks.

If we never see the NULL lets just drop the WARN. In general we prefer
not to scatter warns everywhere.

Can you resubmit without it?

Thanks!
John