From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 A2B6E39A7F5 for ; Sat, 13 Jun 2026 01:36:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781314618; cv=none; b=NRnoFDN6ak1CMNQ/8DL40FHvzkJPV7qHXNJHftPbuSBxqXs/kt554tmK/mpS88jAhASQkHH4WP5RAHJHYc0YikRQkHs8lcDgF4w5cP6It7G5IEzoSf5MgZJWmT3Olw/Zdgc7dpNW1sy3wZAj1E9AMCvaOCb58HIltQb6fwPhW+Q= 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.44 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-f44.google.com with SMTP id 46e09a7af769-7e6deacafa8so1646325a34.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=eTlxpBk/WymiR3llTWEswcIZIGUG43kNOxHEE/0er9uVWHrLR3lRGBAEW3ytU2XVhG bI/4CDRb9DZwADU8rjxYAn1zjlNKdmkcQkwINhVUB4xIRXPMHncSb68/4s2chRPxx7P5 W1rNSOPmX/deJ0yyEgp8MCNri/apxB7pQ/FRboa/I7LZjA0nXh1rLilP8Jjw2fARecLv a3FTRjndv77hFP3eoo4WgMfsaerX9FCDy06ZSE/sASASyAYnbHOruoD2l6Ne85+PNI88 Er0lr24FAYYACeB1YAsvA7DjB4NUQMc3FNJ1ufRadmCERkJcahuh49GeefyVDP01h6fG y1YQ== X-Forwarded-Encrypted: i=1; AFNElJ9ejunkzJMwScfg7JAcTvMGK1cYRA6wLpXQG5TVGE6DkSw8ebzM5AMaCq9qu4zcWHhOXn0ITCs=@vger.kernel.org X-Gm-Message-State: AOJu0YxOpqR33FhqCcdeoGt8SCZ3s0kNAh2LVHw4heGLM+3GfbJsuISn Zb9hO7bwuRJWqNk94JIkJS4/b6u9ZvUXW0P4z8DU09iEDbi/77vXu6WV X-Gm-Gg: Acq92OH1VScPiW1S9K1o/xSMRz8FQRs4jawi2RMVMj26U3thXSvRP5PUWq1RHJqyeF6 HAr4Gk8RsZrNnHSFEb4bae1wQ0GyWMI3qz7x1al7+EUft2XieqvECiA09NsZTtJBQma91CjFpt0 NWNorC6zERKxAH7WVBKP4EpD53Pb7csbw7N7DFmYIAHo8CpHDnvoBehXyfwan1Erul8OFg+LtV/ //lunSd8V7iYF0uX+CKBJ4wzYcZTvyiU2ZGIOQhUH4FrE81Vwa2fe8n4rfVq23xjzCZKFFyfDgM CQywzrdSqjTkTAU7UWJBpUNyxiYm5y7B8Uc5Qf/RotF6oSL5RJHQ152LOpz5a1wv4PAunW6g1qp JJBsjIgzrlrtts/Oa3ElBM5lR4Fg6u8dSiivUB1JZn5aTWK56WRr3ZToe0+36HvxR61PWfXjEbs QRRIk886V7ZJUETHE46SniWjuRBzx9fdG1GBSAcJU0PPxOyyv7Pk2wldS37llYdu+/XgKOz0xnL YH/eKe4BFlKV4Or 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: netdev@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