apparmor NULL pointer dereference on resume [efivarfs]
Al Viro
viro at zeniv.linux.org.uk
Tue Mar 11 17:15:34 UTC 2025
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.
More information about the Linux-security-module-archive
mailing list