Re: Does audit work on stable/12? Audit-related panic on latest stable/12

On Mon, Oct 18, 2021 at 7:02 PM Lev Serebryakov <lev@freebsd.org> wrote:
>
>
>   I've upgraded one of my servers from 11.4 to latest stable/12. This server is unique in me fleet because it has audit (and auditd) enabled.
>
>   First of all, right after (source-based, buildworld & Ko) upgrade dmesg becomes flooded with:
>
> BSM conversion requested for unknown event 43224
> BSM conversion requested for unknown event 43225
> BSM conversion requested for unknown event 43234
> BSM conversion requested for unknown event 43238
>
>    And after several minutes of work I've got panic:
>
> Sleeping thread (tid 101199, pid 51147) owns a non-sleepable lock
> BSM conversion requested for unknown event 43224
> KDB: stack backtrace of thread 101199:
> #0 0xffffffff804d0f34 at mi_switch+0xd4
> BSM conversion requested for unknown event 43224
> BSM conversion requested for unknown event 43224
> #1 0xffffffff8051ca2c at sleepq_wait+0x2c
> #2 0xffffffff80467d62 at _cv_wait+0xf2
> #3 0xffffffff80719573 at audit_commit+0x243
> #4 0xffffffff80719866 at audit_syscall_exit+0x26
> #5 0xffffffff804d7f8a at kern_thr_exit+0x14a
> #6 0xffffffff804d7e37 at sys_thr_exit+0x67
> #7 0xffffffff807a1557 at amd64_syscall+0x387
> #8 0xffffffff8077a7ae at fast_syscall_common+0xf8
> panic: sleeping thread
> cpuid = 6
> time = 1634604615
> KDB: stack backtrace:
> #0 0xffffffff8050e925 at kdb_backtrace+0x65
> #1 0xffffffff804c5bcb at vpanic+0x17b
> #2 0xffffffff804c5a43 at panic+0x43
> #3 0xffffffff80523702 at propagate_priority+0x282
> #4 0xffffffff805242cc at turnstile_wait+0x30c
> #5 0xffffffff804abd29 at __mtx_lock_sleep+0x199
> #6 0xffffffff804d7ec2 at kern_thr_exit+0x82
> #7 0xffffffff804d7e37 at sys_thr_exit+0x67
> #8 0xffffffff807a1557 at amd64_syscall+0x387
> #9 0xffffffff8077a7ae at fast_syscall_common+0xf8
>
>
>    Now, I've turned off auditd and server looks Ok (at least, it is stable for 30 minutes). But I need audit on this server. Is it known problem? Is it configuration problem?
>
>
> --
> // Lev Serebryakov

audit has at least some coverage in CI, but apparently not enough.
Would you share your /etc/security configuration?  Event 43224 is
thr_new, which certainly should be known everywhere, so I'm wondering
if you have a bad build somehow.  Are you using GENERIC or do you have
a custom kernel config?