From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BAB93A4F2F for ; Mon, 1 Jun 2026 13:34:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780320879; cv=none; b=Nb805CrHg12tJ+qy3yNC46dkfyWe+Rw8C7MWG44nSHDTVnckaMELsckWjAlxTpBL/OfihhCDekAqAp1omS2p8QtRIC9Pg78L/mzvMPLFZ0gicq8rQJkQZ0IrTb71bwtxv5AKYuRJmx2CLSxACwG0U0aN6k6QK+z5G+ssYAvp/fw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780320879; c=relaxed/simple; bh=X8caLbf7VqM/HUny6jQVmEvKfAvjcQdyohYFfe5hNww=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kseJ0HXKxdiVvwpmULWyrNkTkhPfIpBgyIZIry5EX8Jmm1mkPthhfFHCsYr+Bx5cCg0tCmBkBmanCzdxgMlxKFnpDx3iGuWXFIsj2WAEnBKoO+bjXSYUN9JLNin4SuZ8o01yalMlLZMIVB07y7xBzzp/1G8YBsUQ0UkD8w+i6p8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=WzjldJ3z; arc=none smtp.client-ip=91.218.175.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="WzjldJ3z" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780320866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QnGI9YHRJnJNK6E7eJ2SMEcHpx+aVb70uazVy8mgK6E=; b=WzjldJ3zTijskKJcuM+oSqk8nWvCIjCLVoP7lmhBXG7pAh0eH0pmbea/PXPKCKdXN7+ykI hhbb6jo1tePpCZUdnveerFjzrzFRExozu0fJzDkpz62ZfrkzVvpPkJkCBrlh+sqLh3RMD8 mTxjsLOysl3zqeIzFqzRRmvU8PLiSUU= Date: Mon, 1 Jun 2026 21:34:07 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf v2 1/4] bpf: Fix TOCTOU issue in lwt To: Alexei Starovoitov Cc: bpf , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrii Nakryiko , Eduard Zingerman , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Kumar Kartikeya Dwivedi , Song Liu , Yonghong Song , Jiri Olsa , Shuah Khan , Guillaume Nault , Ido Schimmel , Fernando Fernandez Mancera , Peter Oskolkov , LKML , Network Development , "open list:KERNEL SELFTEST FRAMEWORK" , kernel-patches-bot@fb.com References: <20260529151351.69911-1-leon.hwang@linux.dev> <20260529151351.69911-2-leon.hwang@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/6/1 08:44, Alexei Starovoitov wrote: > On Fri, May 29, 2026 at 8:14 AM Leon Hwang wrote: >> >> Sashiko pointed out [1]: >> The hdr pointer passed to bpf_lwt_push_ip_encap() can point to concurrently >> mutable memory such as a BPF map value. >> >> So, the memory of hdr pointer can be updated after skb_postpush_rcsum(). >> >> To fix it, memcpy() the hdr to a local buffer, which will be used for the >> following checks and updates. >> >> [1] https://lore.kernel.org/bpf/20260525150010.CDEBA1F000E9@smtp.kernel.org/ >> >> Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") >> Signed-off-by: Leon Hwang >> --- >> net/core/lwt_bpf.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c >> index f71ef82a5f3d..8009e427851f 100644 >> --- a/net/core/lwt_bpf.c >> +++ b/net/core/lwt_bpf.c >> @@ -599,6 +599,7 @@ static int handle_gso_encap(struct sk_buff *skb, bool ipv4, int encap_len) >> >> int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool ingress) >> { >> + u8 buff[LWT_BPF_MAX_HEADROOM]; > > extra 256 bytes of stack to partially close a hypothetical issue > is not worth it. > Ignore such AI complaints. > Not every "bug" needs a fix. > If a malicious bpf user wants to crash the kernel they will > find a way to do so. Especially with agents. > We cannot realistically close all of the holes. > Right now the priority is to fix the issues that normal > users can hit and not bots. > Ack. Will focus on the fix for encapsulating VxLAN in lwt. Thanks, Leon