From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 7BBE92D3ECF for ; Sun, 7 Jun 2026 16:55:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780851354; cv=none; b=UA5XdsghEIzkfUWRuRthhOPYjS0bZNRo3yvrYzMiLBHY3IvQDaOA57CtoanAusva2VM2tshisdMxPUEFcFlhWxHC3zOhxEC/afFn+A7shFydbGjCA2Kf1NmIU7dUXmq+Eeg1CRD64N3miiF0VAa5grNg1Sd7pgpRzA0T2MAIK1Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780851354; c=relaxed/simple; bh=vq0VLS/ylpM3CmAEtZEwDI7OGBBgEUHxL8PTx+OEr9E=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=ribXCwhVzjfdbkwqCy3kL0sAFdRJ27k96BAWhC7r4+yGgLF4AK99nLqcFI8y9Jtu8yDa8u16D7zvdC9q5ilKl8b8rJUHk5RWTuMFbo1Aj+xXrd2hcE66ytdhp91GS2O7aol8T6eJ+UR796UzIDbwisYxWVXWlgBd7arSy3G9Pkg= 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=myKldV5g; arc=none smtp.client-ip=209.85.167.175 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="myKldV5g" Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-48611862583so1590280b6e.0 for ; Sun, 07 Jun 2026 09:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780851351; x=1781456151; 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=X3oVPDjM9UNiAad2kRETnB/VhLXES/+/2f8UxjTzkJ8=; b=myKldV5gKWkOayJ8U/ypJOEEHBRkDxE7v6Hy0Nq01Lqk/TwIAcjO028egEo65OTyAd DdXY3lBxFAmqNvqAMpFJZpI1kLLn6CTliJpCvgkWcTILaYNLTNffoGzCJL4Mgqzh0/cj 5vmXrKXmpT9VvguBA2uQ9qL70jxmJQczNqFOvBMuhHu1FZH/77JeKuw7/V8xQWaLzDx2 LK37ACEanT6iXhPrJseRltQm3oc32HBVCBjJkkCAjATaRy08+4xOpMqtBJR1ekg1o7wd 2V9ZNQj5FzVerFkOm7jSYpo7Dy5GpqWw688rx/WCOcbySVkzF+u5PVtMJ0zB1SvKRrp2 R1QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780851351; x=1781456151; 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=X3oVPDjM9UNiAad2kRETnB/VhLXES/+/2f8UxjTzkJ8=; b=T/W6LO84UEtHJ7r9HgqNRLI+MvVFK+wNc4/z0KRNXF4eInHS3IV3H+olxHR6DOi73g 2IE2dbCiU9RNy+bExElqJiE82DVJQBVKgUJIeS/XKXeS40GxQ/zRzEIDwK6oYI92tYgM i2SzrPJU0nAmNVm+Lj1pCA403PlI2TQssx3M88//ZDq/+FzlsOtE5eQcRo8GvVRo2eeT lW7ewMR1gf9cA5vOLIJfqvZEfOTiXzGU5GEYP+1eGQ6gFqzMGqwA24hoEMfIP7Ifq/OQ Yd+mxIphHp/vl0cDX4mEvpA1HnhXK8xuOe2LGckejmgq6ia321tU6pBaPNTgBFvkhsW/ GvFA== X-Forwarded-Encrypted: i=1; AFNElJ8DBCugvWU7YCzLdnSVpRtvq34auTEeBdkW1jW7Oykh3hdZ0qovgsrUHICTVSlX+QM1O4ZbgKzEfUj15uI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4LdEA/SMVa572OdtRHR8GjTctu5BG8+7j4kxiA5KOvatDaD3C yw4H+GFG8Ds3Hq65OsYVvMvK63QJ5Fj039Dv4Ray/UxOFfowN1DYh5K5JhZTfQ== X-Gm-Gg: Acq92OGWWTrjVqmznvGAcSTplvwnOEX3jR/W5LxOyXq3M5mf+wcp7AIjV4aCeP9tc5P u7al4UjxgCZ1FFHNEXG3MYFR9W4/tCbzNIXUnc/bs8EnbmbiGTfACG+Nrp9ZMoxJC8ShVPbYTMY ju6TYOriMfKtm1IqqmV1YcXIcX3cOnOGqx/fA2PtXDYIzLbANPodrwvqogj7mEqDK95/JKvCrgd h3LjGDQfJS66GfJ07QZ13Z3afFE3fpRsxjwPbqk2dTg8TsdXUR4gD0QRhDehEa1nl2IaC63SS5O H6UaXDXBuN26hH1O+2NQC+rPdJkfqfaZ7SlbrNAsHBhaOpDqAks+CPH1mu1wyUvqi8mTm4PTsi6 RGZJf4Sloos0Rm6Ry0mjmJoelLsOW7uNv7fqnNWF4cl0T5Coh9+Sn74ZqjDc37F2h7NTTaEkCvT 6zspM9HjeVfShO3r2M9briiz7/gf/KsaJqkIpa17UjmqhwFtNtsXMvljGwp62lbolDJXCL4spJG HNgkmPymIjAzMAPLVPmMxGJe8ER X-Received: by 2002:a05:6808:181c:b0:486:4bd0:9a29 with SMTP id 5614622812f47-4868df0166fmr6506417b6e.43.1780851351218; Sun, 07 Jun 2026 09:55:51 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:52::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-440d7263efcsm14254294fac.0.2026.06.07.09.55.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2026 09:55:49 -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: Sun, 07 Jun 2026 09:55:47 -0700 Message-Id: Cc: , , , , , Subject: Re: [PATCH bpf] bpf: Validate BTF repeated field counts before expansion From: "Alexei Starovoitov" To: "Kumar Kartikeya Dwivedi" , "Paul Moses" , , , , , , X-Mailer: aerc References: <20260605234301.1109063-1-p@1g4.org> In-Reply-To: On Sun Jun 7, 2026 at 1:59 AM PDT, Kumar Kartikeya Dwivedi wrote: > On Sat Jun 6, 2026 at 1:43 AM CEST, Paul Moses wrote: >> btf_parse_struct_metas() walks user-supplied BTF during BPF_BTF_LOAD, >> and btf_repeat_fields() expands repeatable fields from array elements >> into the fixed BTF_FIELDS_MAX scratch array used by btf_parse_fields(). >> >> The remaining-capacity check performs the expanded field count calculati= on >> in u32. A malformed BTF can wrap that calculation, causing the check to >> pass even when the expanded field count exceeds the scratch array >> capacity. The following memcpy() can then write past the end of the >> array. >> >> Use checked addition and multiplication before copying repeated fields >> and reject impossible counts. >> >> Fixes: 797d73ee232d ("bpf: Check the remaining info_cnt before repeating= btf fields") >> Cc: stable@vger.kernel.org >> Signed-off-by: Paul Moses >> --- > > Do you have an example where this actually occurred in practice? > >> kernel/bpf/btf.c | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c >> index a62d78581207..510aa32847da 100644 >> --- a/kernel/bpf/btf.c >> +++ b/kernel/bpf/btf.c >> @@ -3668,7 +3668,7 @@ static int btf_get_field_type(const struct btf *bt= f, const struct btf_type *var_ >> static int btf_repeat_fields(struct btf_field_info *info, int info_cnt, >> u32 field_cnt, u32 repeat_cnt, u32 elem_size) >> { >> - u32 i, j; >> + u32 i, j, total_cnt, total_repeats; >> u32 cur; >> >> /* Ensure not repeating fields that should not be repeated. */ >> @@ -3686,10 +3686,9 @@ static int btf_repeat_fields(struct btf_field_inf= o *info, int info_cnt, >> } >> } >> >> - /* The type of struct size or variable size is u32, >> - * so the multiplication will not overflow. >> - */ >> - if (field_cnt * (repeat_cnt + 1) > info_cnt) >> + if (check_add_overflow(repeat_cnt, 1, &total_repeats) || >> + check_mul_overflow(field_cnt, total_repeats, &total_cnt) || >> + total_cnt > (u32)info_cnt) >> return -E2BIG; The callers of this function do: if (nelems > 1) { err =3D btf_repeat_fields(info, info_cnt, ret, nelems - 1, = t->size); so repeat_cnt cannot overflow. 'ret' (which is field_cnt) comes from btf_find_struct_field(). To overflow the struct needs to have 32k valid fields. Is this really what is happening? The issues is deeper. Please have a reliable reproducer first.