On Tue, Jan 5, 2021 at 7:38 PM Al Viro [off-list ref] wrote:

On Tue, Jan 05, 2021 at 07:00:59PM -0500, Paul Moore wrote:

...

quoted

I would expect the problem here to be the currently allocated audit
buffer isn't large enough to hold the full audit record, in which case
it will attempt to expand the buffer by a call to pskb_expand_head() -
don't ask why audit buffers are skbs, it's awful - using a gfp flag
that was established when the buffer was first created.  In this
particular case it is GFP_ATOMIC|__GFP_NOWARN, which I believe should
be safe in that it will not sleep on an allocation miss.

I need to go deal with dinner, so I can't trace the entire path at the
moment, but I believe the potential audit buffer allocation is the
main issue.

Nope.  dput() in dump_common_audit_data(), OTOH, is certainly not
safe.

My mistake.  My initial reaction is to always assume audit is the
problem; I should have traced everything through before commenting.

OTTH, it's not really needed there - see vfs.git #work.audit
for (untested) turning that sucker non-blocking.  I hadn't tried
a followup that would get rid of the entire AVC_NONBLOCKING thing yet,
but I suspect that it should simplify the things in there nicely...

It would be nice to be able to get rid of the limitation on when we
can update the AVC and do proper auditing.  I doubt the impact is
anything that anyone notices, but I agree that it should make things
much cleaner.  Thanks Al.

-- 
paul moore
www.paul-moore.com