Can AUDIT_LIST_RULES causes kthreadd-spam?

[Rinat Gadelshin]

On 06.05.2023 09:50, Tetsuo Handa wrote:
> On 2023/05/06 7:12, Rinat Gadelshin wrote:
>> The only one `auditctl -l` request was performed.
>> I see the following response in syslog for the request:
> Thanks for rules.
>
> I tried "auditctl -l" with these rules, and I got only
>
>    audit: Started audit_send_list_thread
>    audit: Calling netlink_unicast (repeated for 32 times)
>    audit: Finished audit_send_list_thread
>
> as output; audit_send_reply_thread is not called in my environment.
>
> That is, for some reason (maybe some process is interfering each other)
> audit_send_reply_thread is needlessly called in your environment?
> In that case, fixing the cause of audit_send_reply_thread being called
> could reduce the spam.
>
> Please try to find who is calling audit_send_reply_thread for many times.
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 9bc0b0301198..bf4fef7da692 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1006,6 +1011,7 @@ static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int
>   	tsk = kthread_run(audit_send_reply_thread, reply, "audit_send_reply");
>   	if (IS_ERR(tsk))
>   		goto err;
> +	dump_stack();
>   
>   	return;

Hi Tetsuo,

I've rebuilt the kernel with 'dump stack()'.

I've got 7 call stacks for the same test (`auditctl -l` and the same 
audit rule list), they are all similar to:

May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025922] audit: Started 
audit_send_reply_thread
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025924] Hardware name: 
LENOVO 21AH00BPUS/21AH00BPUS, BIOS N3MET11W (1.10 ) 12/07/2022
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025926] Call Trace:
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025928]  <TASK>
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025929] 
dump_stack_lvl+0x4c/0x70
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025935] dump_stack+0x14/0x20
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025936] 
audit_send_reply.constprop.0+0xcc/0x120
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025939] 
audit_receive_msg+0x26d/0x1070
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025940]  ? 
string_nocheck+0x4f/0x60
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025942]  ? string+0x4e/0x60
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025943] 
audit_receive+0xb9/0x180
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025944]  ? 
netlink_deliver_tap+0x49/0x250
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025947] 
netlink_unicast+0x1b2/0x260
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025948] 
netlink_sendmsg+0x254/0x4d0
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025950] 
sock_sendmsg+0x9d/0xb0
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025952] 
__sys_sendto+0x122/0x1b0
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025954]  ? 
__handle_mm_fault+0xac0/0xd10
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025956]  ? 
__audit_syscall_entry+0xd2/0x140
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025958] 
__x64_sys_sendto+0x2d/0x40
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025959] 
do_syscall_64+0x5d/0x90
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025962]  ? 
exit_to_user_mode_prepare+0x3d/0x190
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025965]  ? 
do_user_addr_fault+0x1bc/0x8a0
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025967]  ? 
irqentry_exit_to_user_mode+0xd/0x20
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025969]  ? 
irqentry_exit+0x3f/0x50
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025970]  ? 
exc_page_fault+0x8e/0x190
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025971] 
entry_SYSCALL_64_after_hwframe+0x72/0xdc
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025974] RIP: 
0033:0x7fe97af368a4
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025976] Code: c2 f7 ff ff 
44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 
00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 30 89 
ef 48 89 44 24 08 e8 e8 f7 ff ff 48 8b
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025977] RSP: 
002b:00007ffdfc78af50 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025979] RAX: 
ffffffffffffffda RBX: 00007fe90900aee0 RCX: 00007fe97af368a4
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025980] RDX: 
0000000000000010 RSI: 00007fe90900aff8 RDI: 0000000000000008
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025981] RBP: 
0000000000000000 R08: 00007ffdfc78afd4 R09: 000000000000000c
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025981] R10: 
0000000000000000 R11: 0000000000000293 R12: 00007fe944461920
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025982] R13: 
00007fe905b31be0 R14: 00007fe905b31bf0 R15: 0000000000000000
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025984] </TASK>
May 10 14:51:52 gadelshin-ri-nb kernel: [ 9381.025989] audit: Finished 
audit_send_reply_thread


As far as I can see, it's the exit of `sendto` syscall.
It seems that the kernel just creates a new kthreadd for each sendto 
syscall.
But I think that I'm wrong and just missing something.