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.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
