Re: apparmor NULL pointer dereference on resume [efivarfs]
From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2025-03-11 17:15:36
Also in:
linux-efi, linux-fsdevel
From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2025-03-11 17:15:36
Also in:
linux-efi, linux-fsdevel
On Tue, Mar 11, 2025 at 12:20:05PM -0400, James Bottomley wrote:
That's the way it's supposed to work, yes. However, if we move to an always persistent superblock and mnt, I was thinking there'd have to be an indicator in the sfi about whether the variables were reflected or not.
Just have a pointer to superblock set at ->get_tree() and cleared at the very beginning of ->kill_sb(), then have notifier bugger off if that thing's NULL or if atomic_inc_not_zero(sb->s_active) fails (rcu_read_lock() is sufficient for memory safety of that). And do deactivate_super() when you are done. That'll give you exclusion with umount. As for the rest of that... fuck it, just have kern_mount()/kern_unmount() inside that. How hot do you expect that notifier chain to be? Or screw playing with open/iterate_dir, but that'll need some thinking - theoretically everything you need is already accessible, but direct access to ->d_lock/->d_sib in there is almost certainly not the right level of abstraction. We already have similar bits and pieces in autofs and ceph, and it's just a matter of figuring out a good set of primitives.