Re: [RFC PATCH] audit: drop BUG_ON() from audit_log_XXX()

On Mon, Jul 27, 2026 at 4:08=E2=80=AFPM Ricardo Robaina <[email protected]=
m> wrote:
> On Thu, Jul 23, 2026 at 5:12=E2=80=AFPM Paul Moore <[email protected]> =
wrote:
> > On Wed, Jul 1, 2026 at 9:20=E2=80=AFAM Ricardo Robaina <rrobaina@redhat=
.com> wrote:
> > > On Tue, Jun 30, 2026 at 4:53=E2=80=AFPM Paul Moore <[email protected]=
om> wrote:
> > > >
> > > > We can easily drop the BUG_ON()s from the audit_log_XXX() helpers a=
nd
> > > > simply return to the caller as we do if we are passed a NULL
> > > > audit_buffer.
> > > >
> > > > Signed-off-by: Paul Moore <[email protected]>
> > > > ---
> > > >  kernel/audit.c | 9 +++------
> > > >  1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > ...
> >
> > > Hi Paul,
> > >
> > > It looks good to me. I agree that it was not worth panicking the
> > > kernel in these cases.
> > > Reviewed-by: Ricardo Robaina <[email protected]>
> >
> > Thanks for taking a look.  As an FYI, I'm dropping this patch as I'm
> > folding it into a larger patchset that I'll post as soon as I have a
> > chance to test it.  While looking at the overflow checks in the
> > logging functions I was "inspired" to fix a number of related problems
> > this afternoon and this BUG_ON fix fit well with the new patchset.
> >
> > > I was taking a look at other BUG_ON instances and noticed a couple
> > > that might benefit from similar treatment:
> > >
> > >   1. In audit_add_to_parent() at kernel/audit_watch.c:375:
> > >      BUG_ON(!mutex_is_locked(&audit_filter_mutex));
> > >
> > >      Couldn't we use lockdep_assert_held() instead?
> >
> > I believe so.  Nice catch :)
> >
> > >   2. In __audit_log_bprm_fcaps() at kernel/auditsc.c:2715:
> > >      BUG_ON(axp->pid_count >=3D AUDIT_AUX_PIDS);
> > >
> > >      This could gracefully return an error instead of panicking.
> >
> > I'm assuming you meant audit_signal_info_syscall()?  If so, yes, this
> > would be another good improvement.
>
> You're right, I meant audit_signal_info_syscall(). I'll prepare a
> patch series addressing both cases, then. Thanks, Paul.

Great, thanks!

> >
> > > I can send patches for these if you think they're worthwhile.
> >
> > That would be great, thanks!

--=20
paul-moore.com