Bug 310651

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

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

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

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

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.

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....

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.

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

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.

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

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.