From nobody Sat Jul 25 03:20:49 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 536D2393DE8; Mon, 20 Jul 2026 03:26:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518007; cv=none; b=ROeVjJvEloiFjAVMx+qMJiDWJOL1cjN1D5xoEM7gErVkeu0ovdUR/G2lgPGx5/0TvP+UXJX9Lzi6q8R5rnmnoRiqU5MsGUnnLlJF9Mf2NSsvm4ODIyr0ZvjWxqCQHy+tTCeFUQu5dYFPAAgRa4LtHFbqeTu3CmILdoe74sLcZJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518007; c=relaxed/simple; bh=2JunEdrPcLhl3BZ8kfAyGiRjIBTY9wGsAlAMNwKo4fg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=U7buImdYb6BPoHyKlhcuedt1I4ummDblxg1WDX5B5iHVhjFyak9x+lPF/6GKw5bBUjJMlFJh/WtWW9DzGE5WIxluV9IyalnXsdbM8iF7IWabCc0s+iASOrunUK/8zJ0DyeJtjEagWEvG/oDL3p0Qnm7itennUovZkDatCphR/Jk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4h3QsK2XGwzYQtxm; Mon, 20 Jul 2026 11:26:13 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 3078E40570; Mon, 20 Jul 2026 11:26:27 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP1 (Coremail) with UTF8SMTPA id cCh0CgDXMm9hlV1q56Z3Bw--.11895S3; Mon, 20 Jul 2026 11:26:27 +0800 (CST) From: Pu Lehui To: bpf@vger.kernel.org, linux-kernel@vger.kernel.org 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 , Pu Lehui Subject: [PATCH bpf v3 1/3] bpf: Fix potential UAF when reading bpf link info Date: Mon, 20 Jul 2026 03:30:53 +0000 Message-Id: <20260720033055.1215477-2-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260720033055.1215477-1-pulehui@huaweicloud.com> References: <20260720033055.1215477-1-pulehui@huaweicloud.com> 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 X-CM-TRANSID: cCh0CgDXMm9hlV1q56Z3Bw--.11895S3 X-Coremail-Antispam: 1UD129KBjvJXoWxJFyfGryUurWUGF4UJw1fZwb_yoW5Xw1rpF W3GFn0ka15ur429F17Zr45urySgF48GFyUtF9rW34FyF1YqFZYg34UCrWfZr9IkF97GrWx X3y2va43Gr17XFUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84 ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWl e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfU8XdbUUUUU X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ Content-Type: text/plain; charset="utf-8" From: Pu Lehui In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by holding both normal RCU and tasks trace RCU read locks before dereferencing the prog, as BPF_LINK_TYPE_ITER support both non-sleepable and sleepable progs. Fixes: f9d041271cf4 ("bpf: Refactor bpf_link update handling") Reported-by: Sashiko Signed-off-by: Pu Lehui --- kernel/bpf/syscall.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 6db306d23b47..2458c68146b9 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3471,9 +3471,10 @@ static const char *bpf_link_type_strs[] =3D { static void bpf_link_show_fdinfo(struct seq_file *m, struct file *filp) { const struct bpf_link *link =3D filp->private_data; - const struct bpf_prog *prog =3D link->prog; + const struct bpf_prog *prog; enum bpf_link_type type =3D link->type; char prog_tag[sizeof(prog->tag) * 2 + 1] =3D { }; + u32 prog_id; =20 if (type < ARRAY_SIZE(bpf_link_type_strs) && bpf_link_type_strs[type]) { if (link->type =3D=3D BPF_LINK_TYPE_KPROBE_MULTI) @@ -3490,13 +3491,23 @@ static void bpf_link_show_fdinfo(struct seq_file *m= , struct file *filp) } seq_printf(m, "link_id:\t%u\n", link->id); =20 + /* prog can be sleepable */ + rcu_read_lock_trace(); + rcu_read_lock(); + prog =3D READ_ONCE(link->prog); if (prog) { bin2hex(prog_tag, prog->tag, sizeof(prog->tag)); + prog_id =3D prog->aux->id; + } + rcu_read_unlock(); + rcu_read_unlock_trace(); + + if (prog) { seq_printf(m, "prog_tag:\t%s\n" "prog_id:\t%u\n", prog_tag, - prog->aux->id); + prog_id); } if (link->ops->show_fdinfo) link->ops->show_fdinfo(link, m); @@ -5535,6 +5546,7 @@ static int bpf_link_get_info_by_fd(struct file *file, { struct bpf_link_info __user *uinfo =3D u64_to_user_ptr(attr->info.info); struct bpf_link_info info; + const struct bpf_prog *prog; u32 info_len =3D attr->info.info_len; int err; =20 @@ -5549,8 +5561,15 @@ static int bpf_link_get_info_by_fd(struct file *file, =20 info.type =3D link->type; info.id =3D link->id; - if (link->prog) - info.prog_id =3D link->prog->aux->id; + + /* prog can be sleepable */ + rcu_read_lock_trace(); + rcu_read_lock(); + prog =3D READ_ONCE(link->prog); + if (prog) + info.prog_id =3D prog->aux->id; + rcu_read_unlock(); + rcu_read_unlock_trace(); =20 if (link->ops->fill_link_info) { err =3D link->ops->fill_link_info(link, &info); --=20 2.34.1 From nobody Sat Jul 25 03:20:49 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5363C23ED6A; Mon, 20 Jul 2026 03:26:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518002; cv=none; b=bcU0AFKZA9IPlyhoebDRWQr5/WGWBECkyRjL7iLHGZA4pF++OMCIAypJbAXudD+hGhDHj827PBRrwuEVzvS0Imas7H+dve1hwH6ufrr6ssM3O4NS+JyoWOrFjJNrmqsl0Lb1NbJ1zgS0ZKjMiHYTFUrl0l/K67LsgZK9lBxnO9M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518002; c=relaxed/simple; bh=q6dk0oOrLvska8vpck0sKSTHW9MxlV3YYypagb6Y+TQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rt/t0UxeIDozvu0SA5ViaBrKpO1IpHw60aZPngWYljRg+9pY10J0mJRE+vtekP/sxXlhet9XmtjKu2H+r1x+poznqt+HwT6u7wWOakYWR4nzt+K3q8ccKpbBYBvl4Vulfq8Q0lqsvnetHM27M6ZKxki8qdbYV6dG/5J4UMo02h0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4h3QsK2VDkzYQtxT; Mon, 20 Jul 2026 11:26:13 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 3A12940594; Mon, 20 Jul 2026 11:26:27 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP1 (Coremail) with UTF8SMTPA id cCh0CgDXMm9hlV1q56Z3Bw--.11895S4; Mon, 20 Jul 2026 11:26:27 +0800 (CST) From: Pu Lehui To: bpf@vger.kernel.org, linux-kernel@vger.kernel.org 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 , Pu Lehui Subject: [PATCH bpf v3 2/3] bpf, cgroup: Fix storage not restored when update_effective_progs failed Date: Mon, 20 Jul 2026 03:30:54 +0000 Message-Id: <20260720033055.1215477-3-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260720033055.1215477-1-pulehui@huaweicloud.com> References: <20260720033055.1215477-1-pulehui@huaweicloud.com> 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 X-CM-TRANSID: cCh0CgDXMm9hlV1q56Z3Bw--.11895S4 X-Coremail-Antispam: 1UD129KBjvJXoW7CF1kCryrXr1xAr4rAryfXrb_yoW8CrW3pF n8J3Z8Ka1Yq39Y9r1kt3y0vrn5uF40qr1UKrZ8Aw1rGa17tasYgryxuryjvFW3ZFsrur1S yrn0vF4qk3WjqFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84 ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWl e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfUOdgAUUUUU X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ Content-Type: text/plain; charset="utf-8" From: Pu Lehui In __cgroup_bpf_attach(), if update_effective_progs() fails, pl->storage is not restored to old_storage. Since new_storage is subsequently freed, pl->storage is left pointing to freed memory, leading to a potential UAF issue. Fix this by saving the old_storage before assigning the new one, and restoring it in the error path. Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on = the same cgroup") Reported-by: Sashiko Signed-off-by: Pu Lehui --- kernel/bpf/cgroup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 4355ccb78a9c..70757ae45934 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -813,6 +813,7 @@ 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; struct bpf_prog_list *pl; @@ -883,6 +884,7 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, pl->prog =3D prog; pl->link =3D link; pl->flags =3D flags; + bpf_cgroup_storages_assign(old_storage, pl->storage); bpf_cgroup_storages_assign(pl->storage, storage); cgrp->bpf.flags[atype] =3D saved_flags; =20 @@ -916,6 +918,7 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, pl->prog =3D old_prog; pl->link =3D NULL; } + bpf_cgroup_storages_assign(pl->storage, old_storage); bpf_cgroup_storages_free(new_storage); if (!old_prog) { hlist_del(&pl->node); --=20 2.34.1 From nobody Sat Jul 25 03:20:49 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AB6E394471; Mon, 20 Jul 2026 03:26:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784517994; cv=none; b=SQvJ+NsL9/y2K6G5x2gsuEXG85y7b+yZl0vRE3b9X+nKtjgJ60VGFNehsE1EdrpylwtNB1g8X7Pb383byE6Z0vQUt5qxm178CUTeuYIlqPNIvJQmwOLmnSkhPTnwU9nBw4I8HRyP/bzlIwa5XLcYcJusFzbOopbuF9/LmBrbbto= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784517994; c=relaxed/simple; bh=0gk4mFeSOQiK1IJwmwNaF3P/DEKzhWLa/a6t+jP/pAM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GFNxU5mR24Oj+M0QmV5ShbvXH39dkAIhWIUQ0dKQKd9zTn9MlRg6PfCwl2sRv8VpMxrvcirfF+vf3STCLJ4HvN+IBlbmS+tjYmzBtfSJX+U3tgMLHblO0cv1ZRkzl+KRYy3Oo7aT/LroQeIGZ7+SuNilIo8sl3urySD+LVqrhCI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4h3Qrq3js4zKHMYs; Mon, 20 Jul 2026 11:25:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 52C6040593; Mon, 20 Jul 2026 11:26:27 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP1 (Coremail) with UTF8SMTPA id cCh0CgDXMm9hlV1q56Z3Bw--.11895S5; Mon, 20 Jul 2026 11:26:27 +0800 (CST) From: Pu Lehui To: bpf@vger.kernel.org, linux-kernel@vger.kernel.org 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 , Pu Lehui Subject: [PATCH bpf v3 3/3] bpf, cgroup: Fix storage null-ptr-deref after replacing prog Date: Mon, 20 Jul 2026 03:30:55 +0000 Message-Id: <20260720033055.1215477-4-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260720033055.1215477-1-pulehui@huaweicloud.com> References: <20260720033055.1215477-1-pulehui@huaweicloud.com> 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 X-CM-TRANSID: cCh0CgDXMm9hlV1q56Z3Bw--.11895S5 X-Coremail-Antispam: 1UD129KBjvJXoWxCF13ArW3Zw17Ar4DXFWrXwb_yoW5ZF4rpF 1DAwn8Kw15X39avFn7J3y2vFyfAa10qr1UKrZ8Xw1Fka17tayFgry7CryYva43uFnrWr1S qw1YqF4jkw1UZF7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm214x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxd M2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjx v20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY 6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17 CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF 0xvE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMI IF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVF xhVjvjDU0xZFpf9x0JUHWlkUUUUU= X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ Content-Type: text/plain; charset="utf-8" From: Pu Lehui Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by properly allocating the storage and comparing the old and new storage pointers. If the storage changed, fallback to update_effective_progs which performs a RCU-safe update of the entire array. If the storage remains unchanged, we can safely retain the fast-path in-place update. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf= _cgroup_link") Signed-off-by: Pu Lehui --- kernel/bpf/cgroup.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 70757ae45934..dad2d6a1d96d 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -1035,11 +1035,17 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp, struct bpf_cgroup_link *link, struct bpf_prog *new_prog) { + 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_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] =3D {}; + enum bpf_cgroup_storage_type stype; enum cgroup_bpf_attach_type atype; + bool storage_changed =3D false; struct bpf_prog *old_prog; struct bpf_prog_list *pl; struct hlist_head *progs; bool found =3D false; + int err; =20 atype =3D bpf_cgroup_atype_find(link->link.attach_type, new_prog->aux->at= tach_btf_id); if (atype < 0) @@ -1059,10 +1065,39 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp, if (!found) return -ENOENT; =20 + if (bpf_cgroup_storages_alloc(storage, new_storage, link->link.attach_typ= e, + new_prog, cgrp)) + return -ENOMEM; + + for_each_cgroup_storage_type(stype) { + if (storage[stype] !=3D pl->storage[stype]) { + storage_changed =3D true; + break; + } + } + cgrp->bpf.revisions[atype] +=3D 1; old_prog =3D xchg(&link->link.prog, new_prog); - replace_effective_prog(cgrp, atype, pl); + + if (!storage_changed) { + replace_effective_prog(cgrp, atype, pl); + bpf_prog_put(old_prog); + return 0; + } + + bpf_cgroup_storages_assign(old_storage, pl->storage); + bpf_cgroup_storages_assign(pl->storage, storage); + err =3D update_effective_progs(cgrp, atype); + if (err) { + xchg(&link->link.prog, old_prog); + bpf_cgroup_storages_assign(pl->storage, old_storage); + bpf_cgroup_storages_free(new_storage); + cgrp->bpf.revisions[atype] -=3D 1; + return err; + } + bpf_prog_put(old_prog); + bpf_cgroup_storages_link(new_storage, cgrp, link->link.attach_type); return 0; } =20 --=20 2.34.1