Greg Thelen wrote:
> Linux stable v5.10.226 suffers a lockdep warning when accessing
> /proc/PID/cpuset. cset_cgroup_from_root() is called without cgroup_mutex
> is held, which causes assertion failure.
>
> Bisect blames 5.10.225 commit 688325078a8b ("cgroup/cpuset: Prevent UAF
> in proc_cpuset_show()"). I've have not easily reproduced the problem
> that this change fixes, so I'm not sure if it's best to revert the fix
> or adapt it to meet the 5.10 locking expectations.
>
> The lockdep complaint:
>
> $ cat /proc/1/cpuset
> $ dmesg
> [ 198.744891] ------------[ cut here ]------------
> [ 198.744918] WARNING: CPU: 4 PID: 9301 at kernel/cgroup/cgroup.c:1395
> cset_cgroup_from_root+0xb2/0xd0
> [ 198.744957] RIP: 0010:cset_cgroup_from_root+0xb2/0xd0
> [ 198.744960] Code: 02 00 00 74 11 48 8b 09 48 39 cb 75 eb eb 19 49 83 c6
> 10 4c 89 f0 48 85 c0 74 0d 5b 41 5e c3 48 8b 43 60 48 85 c0 75 f3 0f 0b
> <0f> 0b 83 3d 69 01 ee 01 00 0f 85 78 ff ff ff eb 8b 0f 0b eb 87 66
> [ 198.744962] RSP: 0018:ffffb492608a7ce8 EFLAGS: 00010046
> [ 198.744977] RAX: 0000000000000000 RBX: ffffffff8f4171b8 RCX:
> cc949de848c33e00
> [ 198.744979] RDX: 0000000000001000 RSI: ffffffff8f415450 RDI:
> ffff92e5417c4dc0
> [ 198.744981] RBP: ffff9303467e3f00 R08: 0000000000000008 R09:
> ffffffff9122d568
> [ 198.744983] R10: ffff92e5417c4380 R11: 0000000000000000 R12:
> ffff92e3d9506000
> [ 198.744984] R13: 0000000000000000 R14: ffff92e443a96000 R15:
> ffff92e3d9506000
> [ 198.744987] FS: 00007f15d94ed740(0000) GS:ffff9302bf500000(0000)
> knlGS:0000000000000000
> [ 198.744988] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 198.744990] CR2: 00007f15d94ca000 CR3: 00000002816ca003 CR4:
> 00000000001706e0
> [ 198.744992] Call Trace:
> [ 198.744996] ? __warn+0xcd/0x1c0
> [ 198.745000] ? cset_cgroup_from_root+0xb2/0xd0
> [ 198.745008] ? report_bug+0x87/0xf0
> [ 198.745015] ? handle_bug+0x42/0x80
> [ 198.745017] ? exc_invalid_op+0x16/0x70
> [ 198.745021] ? asm_exc_invalid_op+0x12/0x20
> [ 198.745030] ? cset_cgroup_from_root+0xb2/0xd0
> [ 198.745034] ? cset_cgroup_from_root+0x28/0xd0
> [ 198.745038] cgroup_path_ns_locked+0x23/0x50
> [ 198.745044] proc_cpuset_show+0x115/0x210
> [ 198.745049] proc_single_show+0x4a/0xa0
> [ 198.745056] seq_read_iter+0x14d/0x400
> [ 198.745063] seq_read+0x103/0x130
> [ 198.745074] vfs_read+0xea/0x320
> [ 198.745078] ? do_user_addr_fault+0x25b/0x390
> [ 198.745085] ? do_user_addr_fault+0x25b/0x390
> [ 198.745090] ksys_read+0x70/0xe0
> [ 198.745096] do_syscall_64+0x2d/0x40
> [ 198.745099] entry_SYSCALL_64_after_hwframe+0x61/0xcb
Hello,
we've also encountered this problem. The thing is that commit 688325078a8b
("cgroup/cpuset: Prevent UAF in proc_cpuset_show()") relies on the RCU
synchronization changes introduced by commit d23b5c577715 ("cgroup: Make
operations on the cgroup root_list RCU safe") which wasn't backported to
5.10 as it couldn't be cleanly applied there. That commit converted access
to the root_list synchronization from depending on cgroup mutex to be
RCU-safe.
5.15 also has this problem, while 6.1 and later stables have the backport
of this RCU-changing commit so they are not affected. As mentioned by
Michal here:
https://lore.kernel.org/stable/xrc6s5oyf3b5hflsffklogluuvd75h2khanrke2laes3en5js2@6kvpkcxs7ufj/
In the next email I'll send the adapted to 5.10/5.15 commit along with its
upstream-fix to avoid build failure in some situations. Would be nice if
you give them a try. Thanks!
