From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f171.google.com (mail-dy1-f171.google.com [74.125.82.171]) (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 CDD42413608 for ; Mon, 15 Jun 2026 17:24:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781544292; cv=none; b=hna6cU8fL+o2FKn48OLAEGBBZr90rvXkQ3mPFZ4UFZh2BdjOzGaFZ6BVrnTqeq17UT848uupugbuaFvuJjyPpBZx/v2A/MWXZZHqbN/eON91NcMXZVLvXIclJkpEk+GjQHlpKYmMGiDfGR0UJcZPmBSmPGVCmJKo8zQnNa54kEk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781544292; c=relaxed/simple; bh=7fzuMVqZiWlY7VpQG0hhed+OjcFW2gxl41QoEBVBNCU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=iPawPMUnek4KhBwYchFmaXmqeQv6+RchZ170aAt7XOaLt2exZwn+nQaY7dIfZxeK3NKAXgxu1KCjoMq9p0+pNieWaSVtNrlo1v+WjmkQKW0pSGnVGTnIhgglbJBet55VfCb+KFCXQpiTvH9nmw9QiLjfYsvHkS/iEPJYyKiSa54= 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=O7IKi4k9; arc=none smtp.client-ip=74.125.82.171 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="O7IKi4k9" Received: by mail-dy1-f171.google.com with SMTP id 5a478bee46e88-304ec41197bso4030925eec.1 for ; Mon, 15 Jun 2026 10:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781544291; x=1782149091; 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=2UjHCgbSnreFpSQDpV6wz1i08tQ/MpANdratRi2gobU=; b=O7IKi4k9qF/QSidUC0pSxtYujFS1At3bSJHve+ydCg5XUOLtfsoWgaqC+tISrsAdqw 6E1+E7L7NoTNESxr5H7n7CnrgDR6c27mvtcm6kyeewjFKSsskHgwWhE+et7VN+CFjfIk waCVw6CV/oymPTm3nrS5Tw0KbIw+uZbNFETQcG2mfSdtvtob/ooDhKvvhb29oCUFXwD6 vB2WdgxUfKTETuDFE4Xv0j1+L2ll1+FtxRDP5yZ5qZpYeRg9KRevXyA6y2IeExhuWXS8 1jBAtYnHrj4tR7wmtSohDwHjfQg0xLQYd13K37u7A+R80NA8/PRX08MYwjrb7ozudp4m G8uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781544291; x=1782149091; 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=2UjHCgbSnreFpSQDpV6wz1i08tQ/MpANdratRi2gobU=; b=n03D1qlnMQgYjeZmjchSJw35euX5ei0fBe+6TXJa+WfsOMekTEIx1mDnSu1jdMBCDH fj0OPB1AH5Ci/YBIQS9D7ef6JakMli5VfdGgnKguU16lgijzdASu0yLR+8/Zr4BOfRHv lD1wVViMAAtW5p/8XQFA+BvoyMUyByfoSAGzpN09Dg0Y+bCijNEGTqjE+ruZziSYE+Q0 KUGD98ZbCMcsqEzA43Q4LK7MegNr8G44dLvkDAyRLnKteTUVS9CWxSeyE6m9pDZowvTW Ksc2eKh+0jVgpM7S/iYESuAtKwTI9cY/EBEkxtxgDdXLktX4/igdN38bmCWyG/LnPCuo ifHw== X-Forwarded-Encrypted: i=1; AFNElJ9yPis6umVAweuFDyKnuDpTGinyPPZ78Om4FZ6oKVTxapK5fxCQzLBBwjHOaWAYb5RrQMfiR3IgZwjioW4=@vger.kernel.org X-Gm-Message-State: AOJu0YyzPiOs7aeeESirCdXZvi9VyBkaXy5ZevvssvPzg32R6iUH5fbT ugKOYsMGnXfxqpwPoCzgJNzkOfkpHSRmGphMBpvZqFfaiJyGc6bX1wbS X-Gm-Gg: Acq92OGqd4m/6KPohkkfCrTEsk6HSWtY6xEPn/D1nYnAX87EKYMhlZIBQWFxLIIhCSs ksIcj66+XiiXD7BtJ/8AMZNtgsF9lW0xiMOJT99ObNfENMvKUxxP7BLF7+wxhuozcy9YSW9EaPF 0mpCYwkZ6Np36bX7GuMpKDZVRc6UaEKlKjwz/irYdFWNLH8ysdpYAVTt2TTUk2neYTM6v6BZnge jnMGzrqn4GU44hZ/A0s8FWmK0Hn3faa6FG7W05nQpMb6WH8TbMMyvdZW6St3N9YfhA7KjBYM7bh 1VYZDldeT5k3K7kpnFDIX0m8nTnw2/UKQbDtXmFkMVEyizKAsfxlIrXrOMTt+1O3vUonwjdXVuD BC6kgZ0Q99J2Pfk9ROFvJBG0+E+421f8rYGgtPs+OFPKmfvFdmtAWcyM6uOi2KHQBvnZZHf6Pdz UuBl74PVrUeVNIIdXAUg45A5Jbb3uPD5fqLe4cI77rynq/igbth/8oVGZQCxph6aDjh78Py3xU1 hs4PDg= X-Received: by 2002:a05:7301:9e46:b0:304:8870:2ac5 with SMTP id 5a478bee46e88-30ba596a8b0mr94631eec.6.1781544290993; Mon, 15 Jun 2026 10:24:50 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:755:4880:8bc0:de02? ([2620:10d:c090:500::3:317a]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3081ea4fe55sm15315382eec.25.2026.06.15.10.24.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 10:24:50 -0700 (PDT) Message-ID: <4d2b2fd4f4c1cbda0e071be8a0d6254c6b6729d2.camel@gmail.com> Subject: Re: [PATCH bpf 0/2] bpf: Preserve rdonly_cast dynptr slice lifetime From: Eduard Zingerman To: Kumar Kartikeya Dwivedi , Nuoqi Gui , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Martin KaFai Lau , John Fastabend , Shuah Khan , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 15 Jun 2026 10:24:48 -0700 In-Reply-To: References: <20260615-f01-09-rdonly-cast-dynptr-lifetime-v1-0-2dd0a369e153@mails.tsinghua.edu.cn> 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-15 at 11:40 +0200, Kumar Kartikeya Dwivedi wrote: > On Mon Jun 15, 2026 at 10:57 AM CEST, Nuoqi Gui wrote: > > bpf_rdonly_cast() is an identity operation at runtime, but the verifier > > currently assigns the result fresh return-state metadata. When the sour= ce > > pointer comes from bpf_dynptr_slice(), that drops the relationship need= ed > > to invalidate the alias when the dynptr is released. > >=20 > > Preserve the dynptr-slice lifetime metadata across bpf_rdonly_cast(), a= nd > > add verifier selftests covering cases where a dynptr slice is cast and = then > > read after the dynptr is released or after the originating dynptr stack= slot is > > overwritten while a clone still holds the reference. Also cover the val= id clone > > case where the cast alias is derived from the clone and remains usable = after > > the original dynptr is overwritten. > >=20 > > This fixes regressions introduced by 66e3a13e7c2c ("bpf: Add > > bpf_dynptr_slice and bpf_dynptr_slice_rdwr") and a35b9af4ec2c ("bpf: Ad= d a > > kfunc for generic type cast"). > >=20 > > Impact is bounded to verifier lifetime tracking for CAP-required BPF > > programs. The evidence confirms stale read acceptance after dynptr rele= ase, > > including a typed field-read shape, but does not demonstrate unprivileg= ed > > reachability, cross-context disclosure, controlled reuse, arbitrary ker= nel > > read, write-capable aliasing, privilege escalation, crash, or KASAN/UAF > > signal. No CVE, embargo, or security escalation is claimed. > >=20 > > Validation: > > - The new dynptr_fail.c subtests exercise the verifier's dynptr-slice > > lifetime invariant across bpf_rdonly_cast(): a cast alias of a > > bpf_dynptr_slice() result must be invalidated when the dynptr is rele= ased or > > its stack slot overwritten, while a cast alias derived from a survivi= ng clone > > must stay usable. >=20 > Won't fix. The semantics of bpf_rdonly_cast() do not require soruce prove= nance > tracking, and thus don't need any invalidation. It can take any unknown v= alue > and produces safe to read pointer. Please try to reason about whether it'= s a > real issue before posting AI's output directly. >=20 > pw-bot: cr +1, the memory access through untrusted pointers is handled via prob-read pseudo-instructions. Nothing to fix here.