Bug 310651

Summary: audit: Logging execve arguments, out of memory in audit_expand (kernel panic)
Product: [Other] Security Response Reporter: Issue Tracker <tao>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: urgent    
Version: unspecifiedCC: eparis, jplans, kreilly, sgrubb, tao
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-02 10:31:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 427532, 429691, 429692    
Bug Blocks: 427392, 427393, 430698    

Description Issue Tracker 2007-09-28 11:48:32 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2007-09-28 12:03:35 UTC
In kernel version 2.6.9-35.1, the following patch was added to print out
the arguments to the execve system call


* Wed May 3 2006 Jason Baron <jbaron> [2.6.9-35.1]
-audit: add execve() argument logging support (Aristeu S. Rozanski F.)
[168285]

This is a problem when using execve with a large number of arguments. The
kernel can run out of memory when creating the audit log message for this
situation and fail with the following oops message

audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=8192
Kernel panic - not syncing: audit: out of memory in audit_expand

------------[ cut here ]------------
kernel BUG at kernel/panic.c:75!
invalid operand: 0000 [#1]
SMP 
Modules linked in: test_module(U) nfsd exportfs lockd nfs_acl sunrpc md5
ipv6 netconsole netdump autofs4 i2c_dev i2c_core battery button ac mii(U)
pcnet32 bond0 floppy libata at
a_piix dm_snapshot dm_zero ext3 dm_mirror jbd mptscsih dm_mod mptsas
mptspi mptscsi sd_mod mptfc mptbase scsi_mod
EIP:    0060:[<c0122106>]    Tainted: P      VLI
CPU:    0
EFLAGS: 00010286   (2.6.9-55.ELsmp) 
EIP is at panic+0x47/0x147
esi: c9f76600   edi: cc5b5ea0   ebp: c5281f44   esp: c5281f0c
eax: 00000045   ebx: c9f76600   ecx: c5281f04   edx: c02e774b
ds: 007b   es: 007b   ss: 0068

Process ls (pid: 13156, threadinfo=c5281000 task=cc3bc6f0)Stack: c013b553
c9f76600 c02e8cb6 c013c3f4 c02e8f42 c02e8f71 c492e992 c492e99c 
       0000000a c492e99d c013c475 cc5b5ea0 c013c5de c02e8f71 cc5b5ea0
c492e992 
       0000156f cafc9c00 c4920000 cc5b5ea0 c013d33d cc5b5ea0 0000156e Call
Trace:
c02e90d9 
 [<c013b553>] audit_log_lost+0x0/0x81 
 [<c013c3f4>] audit_log_vformat+0xdc/0x148 
 [<c013c475>] audit_log_format+0x15/0x16 
 [<c013c5de>] audit_log_untrustedstring+0x5c/0x68
 [<c013d33d>] audit_log_exit+0x1a2/0x3da
 [<c013da19>] audit_syscall_exit+0x108/0x3ef [<c0164f51>]
 do_execve+0x1f3/0x1fd [<c010a0b1>]
 do_syscall_trace+0x2f/0xca
 [<c02d5f96>]
 syscall_exit_work+0x12/0x18

Code: 41 c0 e8 b7 0a 0e 00 68 60 97 c0 41 68 4b 2e 77 c0 e8 01 08 00 83 00
c4 0c 3d ce 83 ac 43 00 c0 75 83 a8 09 3d ce c0 74 <0f> 43 00 08 0b 4b 6e 
2e 00 77 c0 c0 31 e8 8a 83 ff e8 4b ff ff 32 ff 31 



This event sent from IssueTracker by sprabhu 
 issue 123090

Comment 2 Issue Tracker 2007-09-28 12:07:04 UTC
To recreate,

#First create a directory with a large number of subdirectories
mkdir audit-test
for i in {1..50}
do
        echo -n " $i"
        mkdir audit-test/aaa-$i
        for j in {1..100}
        do
                touch audit-test/aaa-$i/bbb-$j
        done
done

#Set audit rules with audit for execve enabled.

#clear all audit rules
auditctl -D
#set audit to just print out messages
auditctl -f 1 
#add a watch for execve logging 
auditctl -a entry,always -S execve

cd audit-test
ls -l */*

This will just printout lines similar to
audit: out of memory in audit_expand
audit: audit_lost=6 audit_rate_limit=0 audit_backlog_limit=8192

However if -f 2 is passed to it, the audit system will cause the kernel to
panic because it was unable to log the event.

The customer CANNOT disable auditing due to federal government
requirements.  Further, this customer CANNOT disable the -f 2 audit rule
(they have to panic if they can't log auditing data, they are required by
law to record everything).



This event sent from IssueTracker by sprabhu 
 issue 123090

Comment 4 Issue Tracker 2007-09-28 12:54:15 UTC
Upstream patches which appear to fix this issue.

http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=469f99e2FPmErI6t10GG-KhJ3rLH-g
http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=46abfe90B3EY7UtHsYsI-alUPoqEhQ




This event sent from IssueTracker by sprabhu 
 issue 123090

Comment 8 Eric Paris 2007-10-03 17:37:26 UTC
upstream work to cut down the size of audit_expand....

http://www.redhat.com/archives/linux-audit/2007-October/msg00004.html

http://www.redhat.com/archives/linux-audit/2007-October/msg00005.html

now I need to figure out what we were doing back in RHEL4

Comment 9 Eric Paris 2007-10-11 14:08:57 UTC
If I build a NON SUPPORTED test kernel that could eat their data, steal their
first born child, and take over the world (but I don't think it will do any of
those things) but should resolve this problem would this customer be willing to
give it a try?  I haven't been able to run my machine so close to the edge that
I get a kmalloc failure with or without the patch, so I want them to test to
make sure it is resolved.

Comment 10 Eric Paris 2007-10-11 20:29:23 UTC
I actually got a box to act up, and although I've got it better, it still isn't
right, so my test kernel is not ready, when i do figure out this new twist I'm
still going to want some testing in your environment....

Comment 11 Eric Paris 2007-10-12 18:17:50 UTC
ok, I found my stupidity (created a small temporary buffer then passed the
original huge buffer to be logged, DUH) and have it fixed.  Seems to be working
well for me.  Let me know if the customer will give it a test.

Comment 12 Issue Tracker 2007-10-16 17:48:12 UTC
Hi Eric,

Yes, the customer is willing to test in their development environment.

thanks,

-- 
Paul Novarese


This event sent from IssueTracker by pvn 
 issue 123090

Comment 14 Eric Paris 2007-10-19 15:04:42 UTC
I see no reason why this BZ report is private.  There is no customer data, no
security sensitive information, or really any reason this issue shouldn't be
public.  We have had multiple parties who seem to be running into trouble
allocating enough memory to go execve argument logging and they should be
allowed to find this BZ.  If noone objects to making the BZ public I will do so
some time over the weekend.

Comment 15 Issue Tracker 2007-10-19 19:57:08 UTC
Hi Eric,

My customer reports that the test kernel did not produce any errors; she
confirmed that her testing did produce the same errors under the original
4.5 kernel.

-- 
Paul Novarese


This event sent from IssueTracker by pvn 
 issue 123090

Comment 34 Mark J. Cox 2008-02-26 11:37:08 UTC
After review we believe this actually doesn't qualify to be treated as a
security vulnerability:

The customers who reported this flaw have a non-default setup specifically
designed to cause a machine panic under OOM situations.  The bug is likely to
trigger the panic under normal operating circumstances, even without a local
malicious attacker, and indeed this is how the reporting customers found this
issue.  

So a local malicious attacker could cause the machine configured in this way to
panic (leaving their traces all over the audit log), but it was most likely
going to panic by itself at some point anyway.

I'm going to therefore remove the CVE name we allocated for this issue.