From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B20D139E191 for ; Sat, 13 Jun 2026 01:36:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781314618; cv=none; b=avp2v6slkl+pH9UyXqBeXAMj0oNbpy+YUQPw1phaCGMQsA2/9H/HqTraxscZ6xIjbKa7DvP6XtlTpsJEBDPiIo/3HHFXgWSjhChLmf8VJaBvXSo+vYms4s9/HjxsbNFtsWVD7W0ZzTpuA6XirgeHoKuuSd31CkSEqA7mXJrGsMA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781314618; c=relaxed/simple; bh=ATCD8YWcyycCwAf5daRrjVD1RP8gGZsuumqpfm7uutY=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=U+Y+m7DIu+f3XpYleJExAioV9PZ5sCNO4NHsAfAh2cXH4ZhczaZjkoyJRolSE/NHDriHe8TmWTAiNP67ff1vw9DvM/JFwNZu7FPl8cTEamAq0i+dOe2tVuUw24eW95L2w0esaYSkEHr1cSuQ6HSKzluXWhcOu2zx/mgUC45pthI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CpY886Fr; arc=none smtp.client-ip=209.85.210.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CpY886Fr" Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7e6b5c374e5so1772220a34.0 for ; Fri, 12 Jun 2026 18:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781314617; x=1781919417; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uvfgZCv77btIU2CurjCFxTmu/1bI2beZuVQe8JJi27c=; b=CpY886FrNj4EQww+vVk87tNbyjOoMjx5GMiDePF0Y5cfPIi/mYw+Z5j18KHqIZZEbg FcDVvF609q7lA5/qi9oCQWCW/F0JTLseILy9f1ltPgHuI+ERjGzNq4trVID7nckeTiEB lcKYy7CuOQtxw0uLSNFJtBBqYZhraCvIM0i2GpgkCGt3IMvKQZhG5pmOwRGoFDizFjrC 0j5mLhEc8kclUYhZE5PWjZLar0R1iPaX0IzytiUn2tQUaz5KdiQ18c6McNxBWis8E8zg ocTy7QMIm5+h12O4CGNre7BV46gPOqf+3Jng+FbkUF/Gr+3vBXrpw2cD9ivkz806XQEi c7Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781314617; x=1781919417; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uvfgZCv77btIU2CurjCFxTmu/1bI2beZuVQe8JJi27c=; b=crB1Hf2GtW4/QQ3CfXtpO1c0w/XBUgwJibrkor2GtHO43/hjYoQ3DY2CxvlrQVKKPo UVXwBMfiZ0hFTSG47rNYkjuglC+m+C/PkFe0cdGmouMv3SbuYTxme1KN6zBAupEe22G7 C2o1fQzLHfzG4dfNGLCDEXomPFySXlKf8d1qh/+8aUwwvMcHeHQ76OILUlN3lKKZrCV7 P4g/y3nPSJLTjqUiv+XpL0frYUcV7IYLZU1As3wv4gpMQ5Hd+2ZhyD44Z4HFl83dciMg 5/wSj5r95vkD6fX23WLBTEN800m2uuYewz7mcR6pplSFYrsdUfsDPitZNCR7MTASpw7B I9vQ== X-Forwarded-Encrypted: i=1; AFNElJ+Jc65lhFxQxW3VJiw0LVuWoiTT12w62Ul+XsKYR6Z1nmhBcKlksgu3tCUHGFFa+2LtTON3yUPOPcc54ec=@vger.kernel.org X-Gm-Message-State: AOJu0YxJCcMm0DE5Vv9EffRE52gEuX6CH60fDnwGodmY6+NIU16F4NuL XhsvAxZ6xrIQm5KWFBMQGs14k0sw41z/2ns1vFT438h6Mb+8UZc6/8V1 X-Gm-Gg: Acq92OE9/pYXzzLIQzrPXZ8osieEORqjvp9dFk68nLlfE/nZnyGX/RtXpE8kTU+0DX+ tRC0CLNjVtZ73Zl2F1BSm/OCAhpT8JTscdc4I7DDtw0VwsJEQOrYMVJyfCz1QpOyaU4ciEQm+IA JGmQnCKlbw7GwEFDgAkl5Bq9aXV1d/VNuj9cQJYKzExwMPnW8kWfU+9NoUaKOeu9WvDAN2GXnOb mbkzqvq7KbMeAQryCBSPE1qXBId4H/NTeY+39NMZUtfhZCyr2RqQ9WTE+R9a3GBV8ouTKTx8ona 8cHqh45hMKkatOxXg0hYQxcq1zfNfFOjAbnFJll0jm6q175UVnRbQshQkRYXgzfucheDoE6QJgX ydqZEydqz9R+EkGBqpN8uSTRjTst3cRzxwTuAbZZsxAt/atljAHPu3LrGiYiO4I+6K5vSBzwuvG V8aCivwjDaip7OaELSuK4iPHUyFFZON4Up/vBxkAniIjYsv372OR5whD6JT4yE8SXKpRFa8hbTH zUJAJ8smfHiv0aC X-Received: by 2002:a05:6808:159c:b0:486:cab8:cb7e with SMTP id 5614622812f47-4872dd9f213mr3099133b6e.1.1781314616544; Fri, 12 Jun 2026 18:36:56 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:6::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-487315b016csm2006539b6e.18.2026.06.12.18.36.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2026 18:36:56 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 12 Jun 2026 18:36:54 -0700 Message-Id: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next v3 3/7] bpf, sockmap: zero-initialize pages allocated in bpf_msg_push_data From: "Alexei Starovoitov" To: "Kuniyuki Iwashima" , X-Mailer: aerc References: <20260612130919.299124-4-jiayuan.chen@linux.dev> <20260613002906.1336958-1-kuniyu@google.com> In-Reply-To: <20260613002906.1336958-1-kuniyu@google.com> On Fri Jun 12, 2026 at 5:28 PM PDT, Kuniyuki Iwashima wrote: > From: Jiayuan Chen > Date: Fri, 12 Jun 2026 21:07:47 +0800 >> From: Weiming Shi >>=20 >> bpf_msg_push_data() allocates pages via alloc_pages() without >> __GFP_ZERO. In the non-copy path, the entire page of uninitialized >> heap content is added directly to the sk_msg scatterlist, which is >> then transmitted over TCP to userspace via tcp_bpf_push(). In the >> copy path, a gap of len bytes between the front and back memcpy >> regions is similarly left uninitialized. >>=20 >> This leads to a kernel heap information leak: stale page content >> including kernel pointers from the direct-map and vmemmap regions >> is transmitted to userspace, which can be used to defeat KASLR. >>=20 >> Add __GFP_ZERO to the alloc_pages() call to ensure the allocated >> page is always zeroed before it enters the scatterlist. >>=20 >> Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel= .org >> Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") >> Tested-by: Xiang Mei >> Tested-by: Xinyu Ma >> Reviewed-by: Jiayuan Chen >> Reviewed-by: Emil Tsalapatis >> Signed-off-by: Weiming Shi >> Signed-off-by: Jiayuan Chen >> --- >> net/core/filter.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >>=20 >> diff --git a/net/core/filter.c b/net/core/filter.c >> index 3e555f276ba80..6e345ca65ca14 100644 >> --- a/net/core/filter.c >> +++ b/net/core/filter.c >> @@ -2832,7 +2832,7 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg= , u32, start, >> if (unlikely(copy + len < copy)) >> return -EINVAL; >> =20 >> - page =3D alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP, >> + page =3D alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP | __GFP_ZE= RO, > > This is a red flag. > > We have a bunch of KMSAN reports due to raw/packet sockets, > which requires CAP_NET_ADMIN, and leave them unfixed although > some people attempted to "fix" them by adding __GFP_ZERO to > __alloc_skb(). yep. It's a bpf prog responsibility to avoid garbage in the payload. pw-bot: cr