From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f46.google.com (mail-dl1-f46.google.com [74.125.82.46]) (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 076DE346A18 for ; Mon, 22 Jun 2026 18:50:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782154231; cv=none; b=ZxqbzgQvDWKwOYtZsGXnFYg+4OCDwksc2++yceoRGvAZE9wWHUFL8i5tWqJGfd5Wh2avolGu97c1ERFRcVlCYGQyVurPSD7CHW76OqEHABaJH2O+eAcxxurNk0HqBH/N0QMDWabDNP3EAJ7X6wX6to70SXjyroA5SHshz8jGMF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782154231; c=relaxed/simple; bh=6CP8ytn9kEga82EaEb6SHoo5YmHT3Lz98rg8ozQ8T00=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=XTy0SCX/fRUNMQoLHVrYok6FQ2qJoMXSMz8YTsc9oZyDwd+uqdk0smJD1uJYOXXfEhn3zb2m+8kRwsydUpdmNPOeeGxR98klg2qtN3yHCry670RnMmuBkLdYv6NhXKa6FmfUVlU/ELlrnwsQIDPji2StOSNh+UYv7BMDkZBVS9k= 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=NC3d6mVk; arc=none smtp.client-ip=74.125.82.46 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="NC3d6mVk" Received: by mail-dl1-f46.google.com with SMTP id a92af1059eb24-139aff562e1so2317032c88.1 for ; Mon, 22 Jun 2026 11:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782154229; x=1782759029; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=6CP8ytn9kEga82EaEb6SHoo5YmHT3Lz98rg8ozQ8T00=; b=NC3d6mVkRkb37NTX3M6DrLbB/ZV99ryheF85ke7g4AqMKVkst8ISHHZqEDs6zzjTng 1HhDnzPhxAD4XCpL8cXg+wsKs0e6CPiHTRXNGImozcuc+RT0JqXraLRXsVUSGwncbmw0 iYZvRsz8cpX08SjMAmREjZw9xVJs0bf4xVzfvXL+OOhzEEoERXeHBADebnCYC7d36n+2 nb3puXv88whNHA6PKWQ6CjuTGU7IiiaEueNMwHo29XHVBW0Q/4gwwG4dwYiFpbVQFI4x UfZV+CzT1Gktpgr9DR5WkdHpAOgnAxQtmIGDCdM7vkhU+xK6/Fox1Du3uTxdFymryG0H mIGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782154229; x=1782759029; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6CP8ytn9kEga82EaEb6SHoo5YmHT3Lz98rg8ozQ8T00=; b=WCZy5cmiMeKKPsjUWF9Y60Oe/TmoFVHA8Q0h+OnVxCCpwOcktFSntXqzj7DodT6qyT zNNpcHWX3AQDSLcU7yADZGpFKFry1VMXnpZ1+qP0K6/ND+b9Dx48s/ERvy7pdTm5lAvl BC3xn1br/zoC7TeGDyoiJ9ZMWZ/ufKxLrp8ubXQSCx/n7JHCCIyuEkg40rGGL0AvqwKZ CXmPgvkjq9FhSWM1BOHjWGkmQCYbNzR6B4i5i/ee3iDvwhnJpnaAEM0V7pmxlK2q2m0B HiarNvANYKzSuKJI1JC0Jzxaqon+2CqrvzkS5J0oYTrI3ONKPuYk20x6qYpDHig5zAtp +kjg== X-Forwarded-Encrypted: i=1; AFNElJ98+1bKAxCIUKqGWmsSaMIY9Rnbm0yakl9DIFAxzPxSuaeRc3b2T5fEaH7ZQSirWILHKekOGkU+qQkL8y4=@vger.kernel.org X-Gm-Message-State: AOJu0YzkMb+9+UtYYrRe72OMSFP5s7sWho81fhEACRjml3wIYV5ArzR9 qD56EuJXi+Z16g5W1psITYCI3qJ56PDqif2OSPR+TXoRa3zJiWzHUODT X-Gm-Gg: AfdE7ckFubGowqsjFR09VtjR5PAkYTuBW56GKunPHFfeCSebR9ythhS73Zw/oxwlfPC q23xzDUfi7jUeeYLLZeIvDqUTlS+kFMuJIwJCN5UKbGRZSBCF5WGItTHLk+a76Vhofb5X32F1QQ 7eh8kWuM5+wJof4dFtJKm7AMTZTXX1H3V6Z5synjC5YppqaVtJpvYij+NlautwQLfylEuzH/hk2 pgKPV3ANVdGuoBU6kPHxpMBgD8F8NgeZy21036jIJJXALOAWDKPyzNiKsCP0w6JY7Y2pfipTP7k yGhoGvH9EZl6fSP5NiXrPDBG4/E33U+gp76wGUO+XPJ4bTtgaHp4St7Wa8uRnzBHsBX/PNpjraY YDGdOjaHaXLtOCT4po3sWyQ/I/sPhshQGpME2uTj1V6Wrd7FEpXMnjbR7sr7WFccYxt12vD+hOy cYyymUDMCDyc0jzjxRA5b6SEnSU51S9bkh7rSlDivzNw5d4WKiGtIpmOla43Osm38+p+E= X-Received: by 2002:a05:7022:b87:b0:12c:2cf8:2f30 with SMTP id a92af1059eb24-139a205d12bmr10025200c88.15.1782154229019; Mon, 22 Jun 2026 11:50:29 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:6e2:c699:67c:63fe? ([2620:10d:c090:500::1:5387]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-139add73a44sm8240512c88.13.2026.06.22.11.50.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 11:50:28 -0700 (PDT) Message-ID: <08299ecffff6d5ba708b8de7693eb12a4775e715.camel@gmail.com> Subject: Re: [PATCH bpf-next 1/2] bpf: Reject flexible-array allocation types From: Eduard Zingerman To: Yiyang Chen , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi Cc: John Fastabend , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Shuah Khan , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 22 Jun 2026 11:50:25 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-22 at 04:56 +0000, Yiyang Chen wrote: > bpf_obj_new() and bpf_percpu_obj_new() allocate the static BTF size for > the selected program-BTF type. A struct type can still end with a > zero-length flexible array, and generic BTF struct walks have special > handling that can accept accesses beyond the static struct size through > such a member. >=20 > Reject allocation kfunc types with trailing flexible arrays before markin= g > the return value as PTR_TO_BTF_ID | MEM_ALLOC. This keeps the > verifier-visible BTF access shape aligned with the object size allocated = by > the runtime kfunc. >=20 > Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") > Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local= percpu kptr") > Signed-off-by: Yiyang Chen > --- Hi Yiyang, thank you for the report. I think this should be handled at the btf_struct_walk() level by checking MEM_ALLOC flag. And there is no need to check if the array is flex or not, checking if the final offset reaches past the allocated object boundary should be sufficient. pw-bot: cr. [...]