Re: [PATCH] audit: fix potential null dereference 'context->module.name'

[wang.yi59]

> On Tue, Jul 24, 2018 at 6:38 PM Eric Paris <eparis@xxxxxxxxxx> wrote:
> > On Tue, 2018-07-24 at 15:55 -0400, Paul Moore wrote:
> > > On Tue, Jul 24, 2018 at 7:39 AM Eric Paris <eparis@xxxxxxxxxx> wrote:
> > > > Would it make more sense to actually check for failure on
> > > > allocation
> > > > rather than try to remember to deal with it later? How about we
> > > > just
> > > > have audit_log_kern_module return an error and fail if we are OOM?
> > >
> > > Generally I agree, checking on allocation is the right thing to do.
> > > However, in this particular case the error recovery for a failed
> > > allocation would likely ignore the record entirely, and I think a
> > > module load record with a "(null)" module name is still better than
> > > no
> > > module load record at all ... and yes, I understand that if the
> > > module
> > > name allocation fails there is a good chance other allocations will
> > > fail and we might not emit the record, but I'll take my chances that
> > > the load is transient and the system is able to recover in a timely
> > > manner.
> >
> > On the load_module() code path passing the error up the stack would
> > cause the module to not be loaded, instead of being loaded with loss of
> > name information. I'd rather have the module not loaded and a
> > name=(null) record than it BE loaded and get name=(null)
> >
> > You've sold me on why Yi Wang's patch is good, but not on why we
> > wouldn't propagate the error up the stack on load/delete. (even if we
> > may choose to delete the module on OOM)
>
> For better or worse most (all?) of the various audit_log_*() functions
> don't return an error code, or if they do they aren't reliably checked
> by callers.  I agree with you that in a perfect world it would be nice
> if an audit failure here would block the operation, but that isn't how
> audit is typically used.
>
> We could presumably fail the record generation on an allocation
> failure and signal a lost record via audit_log_lost()?  Perhaps that's
> the best option as it would leave the decision up to administrator
> (continue without the record, printk, or panic).
Thanks everyone for your review and advice! I will submit a v2 patch soon
using kstrdup() and recording the lost with audit_log_lost().

---
Best wishes
Yi Wang