From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (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 A6E9830D406 for ; Thu, 30 Jul 2026 06:33:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785393234; cv=none; b=QnLylSlyPRQvmLtEmAD95if/fNi5a7QO5awKK8uq28F+WFfnAbpDmFuxjsSv7WRY/qr0Bh9q68gcsad9Or/0TEGO80nEsOwYFf4mG7BoklPCrtljoqAzRvZHu3ddFm6PDnV6lpHty03YvYB7WAThvWmbGEdgQ5SAH+giB7Z85Gs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785393234; c=relaxed/simple; bh=1buAZ1J3EJzoK3uKXKjU8iSDVuQnXlUsbpZQK3NC29U=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:From:To:Cc: References:In-Reply-To; b=RDZ/h8jc1v+9uwshtrr01WsW7Xc0PTACZrMWAY71XsqbXBNXKQrBKHquWRvMcPeDnk4SBbOjNh66RgflukI4ChMu5BpMQMwF5K6UJojg6QSXm/9TJn0kOQUeonTPFs6VNaBZ2PCS6NiBU00L999JAHMjOoY2voWHVJ87yvXF0A0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com; spf=pass smtp.mailfrom=etsalapatis.com; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b=w8/bRkfL; arc=none smtp.client-ip=209.85.210.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b="w8/bRkfL" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-8423f236418so1412575b3a.1 for ; Wed, 29 Jul 2026 23:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20251104.gappssmtp.com; s=20251104; t=1785393232; x=1785998032; darn=vger.kernel.org; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=mmztpyGDT8bXM2TJcNunZC5IJZ+7bFWL4gwiWczYTvc=; b=w8/bRkfLWuCSkZLyzKyPtgJPSq27rBmNSb3ShYEQsr49NjJAtspoHIg55jNjQzpxxw n5bH9u83YHuyw0tjWrvckXwV6DStqLSdc6zKdwYfPUJrnGwZVgIsPfnn0qJYzwk39s41 KGV0EDTj95zciNj+a5JoZ6LRjzgaSxUnQXJ0o8ApqOPA8j1cNZfY32boE1tEMitwm6H5 2HAIl/WpnWvlRRamsuYGUxOQ1ruokZFJzgiUIkRjeJHcSapqBrijurEDB8GSdPwwGPmW pK4ina6WUBhg5taYJjZ7iVk7co3pWDDnd3N7jCUojcaRPSVbQK5VJli9XWLUc4Gm0vRn EP8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785393232; x=1785998032; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mmztpyGDT8bXM2TJcNunZC5IJZ+7bFWL4gwiWczYTvc=; b=ru3Z3EnUXFfWC+7TxK2MEw1pujTUcq4va//mFgaEH2Wwa2BFYn66CreDe4bgMLo9Sa dtwnEUGHWEXXaRqTeppdgp27rIAyYGTxpSV2gs1Ld2L31LMrUw8bkQLqoPxtEBkRTlp2 7gmhpNooUCrALglfxaVFgV7jjfNOb4Y9B3KPO/IK3Kq3DrjLkFNQrV1s9Jy6SIdlVw0k oiy2Csevip2DiZJ/mYIoOYATd9owd/idb0oFOVg+25twGT+sE7JmntMaFHAX/GWMve8l 9/UYZjhz/WG79CQbB4xWyMVL+uZ2wGPA/SpgV0Z5YsLoWmgyrjN5rx4lErZd22xRL86d Czyg== X-Forwarded-Encrypted: i=1; AHgh+Rqtb8LullkIX5ahZVUFyxQZPCjEITQWbqFM7BewGrmWr9hBi5PedbE/D/MkUDg+pGwJg0gwOpMa8LRXuWw=@vger.kernel.org X-Gm-Message-State: AOJu0YwfZp5/Peq0ORQ1sVdE7joDo+n0OsKiNOW13/sYHLBEQgFUoVDw iIDpHFfsxhkWXKwBXmXAvoGMN/fqF3OdKnioeT+AN/hSCni9GI2CcOGExFZ+FYhsZ+s= X-Gm-Gg: AR+sD13nqYElFrTiGajAHVoaXAbWpetmsdXCV7y3E0yPMtGtLCwbvsTwlq01aLY842U qggbGbpJEmVxsq5oESW5QV5I+j8BNnUKam6QtCwSIhmkE8Xx63NU2jLtjeNwyyLlmpilkSbH+EQ 5oDih64k+3QP7ms6qlC+XWNLxboEmCdhDGsaWFzrVkrDjRzJayzhkif25HWYHamNitL6zkbMazw sf6vm7PVRD6zAgSF+6Sw0kuXqZYiE2O4huwwwHIAqXq4T249Bw/8SmKp/S4PxLmljcTn3ZebTTz t83UMDQ5jyhCfMf5cuPqZfE16/YtojQu+enVYvBGpT45ZkCg4tigk4FSf/Vjgg7V40SHZt5B06k dbBOLh75XaDqkFbHzXKOM93YzrTEnSztRZU//JPpPLAJmAWjPgDvnW+RZ/ekGUzGqgHB5L0u3ON TU6DEWFNAgO8MXYqTGjcxnnT6Obw5046qsNGojwzjNeMutnRc+1xBYrT2F5+xo8kVbDZ35h77w6 QdRfxECslZPE+Akq9nipT88Mppy X-Received: by 2002:a05:6a00:1748:b0:84e:1c87:e6dd with SMTP id d2e1a72fcca58-84ebc1fd7efmr1496664b3a.7.1785393231861; Wed, 29 Jul 2026 23:33:51 -0700 (PDT) Received: from localhost (107-190-31-17.cpe.teksavvy.com. [107.190.31.17]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84ea03869d2sm2439128b3a.49.2026.07.29.23.33.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2026 23:33:51 -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: Thu, 30 Jul 2026 02:33:50 -0400 Message-Id: Subject: Re: [PATCH bpf v2] bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed From: "Emil Tsalapatis" To: "Pu Lehui" , , Cc: "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Martin KaFai Lau" , "Yonghong Song" , "Song Liu" , "Jiri Olsa" , "Emil Tsalapatis" , "Pu Lehui" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260729100208.3076769-1-pulehui@huaweicloud.com> In-Reply-To: <20260729100208.3076769-1-pulehui@huaweicloud.com> On Wed Jul 29, 2026 at 6:02 AM EDT, Pu Lehui wrote: > From: Pu Lehui > > Sashiko reported a potential invalid storage access issue after > replacing a cgroup bpf prog. > Nit: No need to mention Sashiko reports in the commit message imo, the Reported-by is enough and imo it makes it confusing for people not familiar with the system. > This occurs in the following scenario: > 1. prog1 with storage is attached to a cgroup in multi-attach mode. > 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach > mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or > update_effective_progs). > 3. A new prog3 is attached to the cgroup in multi-attach mode. > > The reason is that __cgroup_bpf_attach overwrites pl->storage with the > new storage prior to attachment completion. When attachment fails > midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to > free the newly allocated storage, but fails to restore pl->storage back > to old_storage. > > Consequently, the still-active prog1 holds invalid or dangling storage > pointers, leading to an invalid memory access when prog1 executes and > calls bpf_get_local_storage. Additionally, original pl->flags and > cgrp->bpf.flags[atype] are left unrestored. > > Fix this by saving old_pl_flags, old_storage, and old_flags prior to the > update, and properly restoring all of them in the cleanup path on error. > > Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs o= n the same cgroup") > Reported-by: Sashiko > Signed-off-by: Pu Lehui Reviewed-by: Emil Tsalapatis > --- > v2: > - Remove the link relative code as link only support > BPF_F_ALLOW_MULTI attach, so will not occur UAF pl. > > v1: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicl= oud.com > > kernel/bpf/cgroup.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c > index e2fa0ebeed83..be24ca453cab 100644 > --- a/kernel/bpf/cgroup.c > +++ b/kernel/bpf/cgroup.c > @@ -813,8 +813,10 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, > struct bpf_prog *old_prog =3D NULL; > struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] =3D {}; > struct bpf_cgroup_storage *new_storage[MAX_BPF_CGROUP_STORAGE_TYPE] =3D= {}; > + struct bpf_cgroup_storage *old_storage[MAX_BPF_CGROUP_STORAGE_TYPE] =3D= {}; > struct bpf_prog *new_prog =3D prog ? : link->link.prog; > enum cgroup_bpf_attach_type atype; > + u32 old_flags, old_pl_flags; > struct bpf_prog_list *pl; > struct hlist_head *progs; > int err; > @@ -865,6 +867,8 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, > =20 > if (pl) { > old_prog =3D pl->prog; > + old_pl_flags =3D pl->flags; > + bpf_cgroup_storages_assign(old_storage, pl->storage); > } else { > pl =3D kmalloc_obj(*pl); > if (!pl) { > @@ -884,6 +888,7 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, > pl->link =3D link; > pl->flags =3D flags; > bpf_cgroup_storages_assign(pl->storage, storage); > + old_flags =3D cgrp->bpf.flags[atype]; > cgrp->bpf.flags[atype] =3D saved_flags; > =20 > if (type =3D=3D BPF_LSM_CGROUP) { > @@ -915,12 +920,15 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, > if (old_prog) { > pl->prog =3D old_prog; > pl->link =3D NULL; > + pl->flags =3D old_pl_flags; > + bpf_cgroup_storages_assign(pl->storage, old_storage); > } > bpf_cgroup_storages_free(new_storage); > if (!old_prog) { > hlist_del(&pl->node); > kfree(pl); > } > + cgrp->bpf.flags[atype] =3D old_flags; > return err; > } > =20