kernfs_add_one() does not always set it. There are two ways it can end up NULL.
One: kernfs_add_one() adds the node to the tree (kernfs_link_sibling) before it sets the map (kernfs_get_ve_perms), both under the sysfs root rwsem. So for a short window the node is in the tree but its map is still NULL. The old kernfs_perms_start() took the wrong rwsem (kernfs_root(of->kn), the cgroup root, not the sysfs one), so it did not lock against kernfs_add_one() and could hit the node in that window. Patch 3 takes the right rwsem and fixes this. Two, separate from the lock: as Vasileios noted, kernfs_get_ve_perms() returns void and only sets the map if kmapset_new() worked, so if that alloc fails the node is left with a NULL map for good. Rare in practice (small GFP_KERNEL alloc) but it can happen, and the NULL check in this patch handles it. I cannot tell from the oops which of the two hit us, but both can happen, and these are the two I found, not necessarily the only ways the map can be NULL. It was crashing repeatedly and consistently under load (a cat storm on ve.sysfs_permissions while the sysfs tree churned), and it reproduced the same way on a stock kernel with no patches. With both the lock fix and this NULL check in place it stopped. I will also explain why the map can be NULL in the commit message in v2. ________________________________ From: Pavel Tikhomirov <[email protected]> Sent: Monday, June 29, 2026 9:14 PM To: Mirian Shilakadze <[email protected]>; Konstantin Khorenko <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [PATCH vz10 2/7] fs/kernfs, ve: skip NULL ve_perms_map in kernfs_perms_shown Maybe there something specific about this kn with NULL ve_perms_map? Why didn't we crash all other the place before? AFAICS, kernfs_add_one -> kernfs_get_ve_perms always sets non-NULL ve_perms_map for each kn. On 6/28/26 11:26, Mirian Shilakadze wrote: > The seq read of ve.sysfs_permissions walks every sysfs node and calls > kernfs_perms_shown(), which feeds kn->ve_perms_map to kmapset_lookup() and > reads ->default_value with no NULL check. A node whose ve_perms_map is NULL > crashes the read (RDI and CR2 are 0, kmapset_lookup() derefs the NULL map > at offset 0x20): > > BUG: kernel NULL pointer dereference, address: 0000000000000020 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > Oops: 0000 [#1] SMP NOPTI > CPU: 82 UID: 0 PID: 10796 Comm: cat ve: 0 Tainted: G W 12.7 PREEMPT(full) > RIP: 0010:kmapset_lookup+0x4/0x40 > RDX: 0000000000000000 RSI: ff2eb351033adf88 RDI: 0000000000000000 > CR2: 0000000000000020 CR3: 0000000c09658001 CR4: 0000000000f71ef0 > Call Trace: > <TASK> > ? kernfs_perms_start+0x60/0xd0 > ? page_fault_oops+0xbb/0x110 > ? exc_page_fault+0x8e/0x100 > ? asm_exc_page_fault+0x26/0x30 > ? kmapset_lookup+0x4/0x40 > kernfs_perms_start+0x60/0xd0 > kernfs_seq_start+0x74/0x110 > seq_read_iter+0xfe/0x480 > vfs_read+0x29f/0x370 > ksys_read+0x73/0xf0 > do_syscall_64+0x92/0x180 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > </TASK> > > Return false for such nodes. kernfs_perms_show() only ever sees nodes that > kernfs_perms_shown() accepted, so guarding it here is enough. > > https://virtuozzo.atlassian.net/browse/VSTOR-136541 > Fixes: 008aa8b6ff0b ("ve/kernfs: add new interface to control per-VE nodes > visibility") > Signed-off-by: Mirian Shilakadze <[email protected]> > --- > fs/kernfs/ve.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/kernfs/ve.c b/fs/kernfs/ve.c > index beaa278b014e..f357ebb907f1 100644 > --- a/fs/kernfs/ve.c > +++ b/fs/kernfs/ve.c > @@ -146,6 +146,8 @@ static struct kernfs_node *kernfs_next_recursive(struct > kernfs_node *kn) > static bool kernfs_perms_shown(struct ve_struct *ve, struct kernfs_node *kn, > struct kmapset_key *key) > { > + if (!kn->ve_perms_map) > + return false; > if (ve_is_super(ve)) > return kn->ve_perms_map->default_value != 0; > return kmapset_lookup(kn->ve_perms_map, key) != NULL; -- Best regards, Pavel Tikhomirov Senior Software Developer, Virtuozzo.
_______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
