Bug 310651
Summary: | audit: Logging execve arguments, out of memory in audit_expand (kernel panic) | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Issue Tracker <tao> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED NOTABUG | QA Contact: | Martin Jenner <mjenner> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | unspecified | CC: | 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
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. |