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

On Wed, Jul 1, 2026 at 9:20=E2=80=AFAM Ricardo Robaina <[email protected]=
> wrote:
> On Tue, Jun 30, 2026 at 4:53=E2=80=AFPM Paul Moore <[email protected]> =
wrote:
> >
> > We can easily drop the BUG_ON()s from the audit_log_XXX() helpers and
> > 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.

> I can send patches for these if you think they're worthwhile.

That would be great, thanks!

--=20
paul-moore.com