Linux-audit Archive mirror
 help / color / mirror / Atom feed
From: cuigaosheng <cuigaosheng1@huawei.com>
To: <cuigaosheng1@huawei.com>, Paul Moore <paul@paul-moore.com>
Cc: wangweiyang <wangweiyang2@huawei.com>,
	linux-audit@redhat.com, linux-security-module@vger.kernel.org,
	Xiujianfeng <xiujianfeng@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Flush the hold queue fall into an infinite loop.
Date: Thu, 13 Jan 2022 19:56:29 +0800	[thread overview]
Message-ID: <8b487a19-d121-5fee-eda5-0aee9340f453@huawei.com> (raw)
In-Reply-To: <96f4f1cb-0e7d-6682-ce33-f7f1314cba83@huawei.com>


[-- Attachment #1.1: Type: text/plain, Size: 4557 bytes --]

When we add "audit=1" to the cmdline, kauditd will take up 100%
cpu resource.As follows:

    configurations:
    	auditctl -b 64
    	auditctl --backlog_wait_time 60000
    	auditctl -r 0
    	auditctl -w /root/aaa  -p wrx
    shell scripts:
    	#!/bin/bash
    	i=0
    	while [ $i -le 66 ]
    	do
    	    touch /root/aaa
    	    let i++
    	done
    mandatory conditions:

        add "audit=1" to the cmdline, and kill -19 pid_number(for /sbin/auditd).

  As long as we keep the audit_hold_queue non-empty, flush the hold queue will fall into
  an infinite loop.

> 713 static int kauditd_send_queue(struct sock *sk, u32 portid,
>  714                               struct sk_buff_head *queue,
>  715                               unsigned int retry_limit,
>  716                               void (*skb_hook)(struct sk_buff *skb),
>  717                               void (*err_hook)(struct sk_buff *skb))
>  718 {
>  719         int rc = 0;
>  720         struct sk_buff *skb;
>  721         unsigned int failed = 0;
>  722
>  723         /* NOTE: kauditd_thread takes care of all our locking, we 
> just use
>  724          *       the netlink info passed to us (e.g. sk and 
> portid) */
>  725
>  726         while ((skb = skb_dequeue(queue))) {
>  727                 /* call the skb_hook for each skb we touch */
>  728                 if (skb_hook)
>  729                         (*skb_hook)(skb);
>  730
>  731                 /* can we send to anyone via unicast? */
>  732                 if (!sk) {
>  733                         if (err_hook)
>  734                                 (*err_hook)(skb);
>  735                         continue;
>  736                 }
>  737
>  738 retry:
>  739                 /* grab an extra skb reference in case of error */
>  740                 skb_get(skb);
>  741                 rc = netlink_unicast(sk, skb, portid, 0);
>  742                 if (rc < 0) {
>  743                         /* send failed - try a few times unless 
> fatal error */
>  744                         if (++failed >= retry_limit ||
>  745                             rc == -ECONNREFUSED || rc == -EPERM) {
>  746                                 sk = NULL;
>  747                                 if (err_hook)
>  748                                         (*err_hook)(skb);
>  749                                 if (rc == -EAGAIN)
>  750                                         rc = 0;
>  751                                 /* continue to drain the queue */
>  752                                 continue;
>  753                         } else
>  754                                 goto retry;
>  755                 } else {
>  756                         /* skb sent - drop the extra reference 
> and continue */
>  757                         consume_skb(skb);
>  758                         failed = 0;
>  759                 }
>  760         }
>  761
>  762         return (rc >= 0 ? 0 : rc);
>  763 }

When kauditd attempt to flush the hold queue, the queue parameter is &audit_hold_queue,
and if netlink_unicast(line 741 ) return -EAGAIN, sk will be NULL(line 746), so err_hook(kauditd_rehold_skb)
will be call. Then continue, skb_dequeue(line 726) and err_hook(kauditd_rehold_skb,line 733) will
fall into an infinite loop.
I don't really understand the value of audit_hold_queue, can we remove it, or stop droping the logs
into kauditd_rehold_skb when the auditd is abnormal?

Look forward your reply. Thank you very much.

Gaosheng.

     


[-- Attachment #1.2: Type: text/html, Size: 5567 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

       reply	other threads:[~2022-01-13 12:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <96f4f1cb-0e7d-6682-ce33-f7f1314cba83@huawei.com>
2022-01-13 11:56 ` cuigaosheng [this message]
2022-01-13 12:16   ` some logs about the issue // Re: Flush the hold queue fall into an infinite loop cuigaosheng
2022-01-13 15:22   ` Paul Moore
2022-01-14  1:22     ` cuigaosheng
2022-01-14 22:35       ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b487a19-d121-5fee-eda5-0aee9340f453@huawei.com \
    --to=cuigaosheng1@huawei.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=wangweiyang2@huawei.com \
    --cc=xiujianfeng@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).