linux-kernel - [PATCH 1/8] audit: avoid soft lockup due to audit_log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <e172e2536b18223179fde70879a589e1ff9a74c5.1379530867.git.rgb@redhat.com>
Date:	Wed, 18 Sep 2013 15:06:46 -0400
From:	Richard Guy Briggs <rgb@...hat.com>
To:	linux-audit@...hat.com, linux-kernel@...r.kernel.org
Cc:	Richard Guy Briggs <rgb@...hat.com>,
	Steve Grubb <sgrubb@...hat.com>,
	Eric Paris <eparis@...hat.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Duval <dan.duval@...cle.com>,
	Chuck Anderson <chuck.anderson@...cle.com>,
	Guy Streeter <streeter@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Luiz Capitulino <lcapitulino@...hat.com>
Subject: [PATCH 1/8] audit: avoid soft lockup due to audit_log_start() incorrect loop termination

Commit 82919919 caused the wait for auditd timeout condition to loop endlessly
rather than fall through to the error recovery code.

 BUG: soft lockup - CPU#0 stuck for 22s! [preload:785]
 RIP: 0010:[<ffffffff810fb240>]  [<ffffffff810fb240>] audit_log_start+0xf0/0x460
 Call Trace:
  [<ffffffff810aca40>] ? try_to_wake_up+0x310/0x310
  [<ffffffff81100fd1>] audit_log_exit+0x51/0xcb0
  [<ffffffff811020b5>] __audit_syscall_exit+0x275/0x2d0
  [<ffffffff816ec540>] sysret_audit+0x17/0x21

If the timeout condition goes negative, the loop continues endlessly instead of
breaking out and going to the failure code and allow other processes to run
when auditd is unable to drain the queue fast enough.

This can easily be triggered by readahead-collector, in particular during
installations.  The readahead-collector (ab)uses the audit interface and
sometimes gets stuck in a 'stopped' state.

To trigger:
	readahead-collector -f &
	pkill -SIGSTOP readahead-collector
	top

See:
	https://lkml.org/lkml/2013/8/28/626
	https://lkml.org/lkml/2013/9/2/471
	https://lkml.org/lkml/2013/9/3/4

Signed-off-by: Luiz Capitulino <lcapitulino@...hat.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@...nvz.org>
Signed-off-by: Dan Duval <dan.duval@...cle.com>
Signed-off-by: Chuck Anderson <chuck.anderson@...cle.com>
Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
---
 kernel/audit.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 91e53d0..7b0e23a 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1117,9 +1117,10 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
 
 			sleep_time = timeout_start + audit_backlog_wait_time -
 					jiffies;
-			if ((long)sleep_time > 0)
+			if ((long)sleep_time > 0) {
 				wait_for_auditd(sleep_time);
-			continue;
+				continue;
+			}
 		}
 		if (audit_rate_check() && printk_ratelimit())
 			printk(KERN_WARNING
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/