Re: apparmor NULL pointer dereference on resume [efivarfs]

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2025-03-11 at 17:15 +0000, Al Viro wrote:
> 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.

OK that works, thanks!

> 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?

The notifier chain itself is somewhat active, but the notifications we
care about occur once on resume from hibernate (so very few, if any).

> 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.

I'll probably stick to getting it to work for now ... the refactoring
can come later.

Regards,

James