Thread (20 messages) 20 messages, 6 authors, 2025-03-17

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

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help