Bug 338761 - execve() fails with ENOMEM with not-too-huge argv[][] b/c of auditing demands
Summary: execve() fails with ENOMEM with not-too-huge argv[][] b/c of auditing demands
Keywords:
Status: CLOSED DUPLICATE of bug 427532
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audit
Version: 4.5
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Steve Grubb
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-18 20:26 UTC by Buck Huppmann
Modified: 2008-04-10 15:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-10 15:58:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
allocation failure messages and bprm_audit frames in dump_stack()'s from a few different machines over a couple weeks (4.95 KB, text/plain)
2007-10-18 20:26 UTC, Buck Huppmann
no flags Details

Description Buck Huppmann 2007-10-18 20:26:03 UTC
Description of problem:

when a moderately large argv[][] is passed from, say, the shell to
execve(), execve() can fail with E_NOMEM, even when
sizeof(argv[][]) is much < _SC_ARGMAX. the kernel logs a page allo-
cation failure and does a dump_stack() and show_mem(), and the for-
mer shows brpm_audit() as the allocating caller

Version-Release number of selected component (if applicable):

kernel 2.6.9-55.0.2.ELsmp

How reproducible:


Steps to Reproduce:
1. get a decent amount of memory fragmentation
2. /bin/ls * in a decent-sized directory (but not too big)
3.
  
Actual results:

sh: /bin/ls: Out of memory

Expected results:

[ls output]

Additional info:

i logged this with our TAM as issue no. 134049, but it doesn't sound like
it's going to get fixed that way. what i'm hoping might be a workaround
that might make it into 5, if it's an issue there, is that, if audit_bprm()
can't kmalloc() enough pages to hold the argv[][] and/or envp[][] it just
grabs enough memory to store argv[][] = { argv[0], "[too much argument
data to accommodate at this time]", NULL }, envp[][] = { NULL }, or some-
thing like that. or does punting like this not accord with the standards
that the kernel audit subsystem is supposed to uphold? can it be configur-
ed to be more liberal? i think that's more security-sensitive than having
to shut it off altogether to keep processes from sporadically failing

thanks for looking into

Comment 1 Buck Huppmann 2007-10-18 20:26:03 UTC
Created attachment 231541 [details]
allocation failure messages and bprm_audit frames in dump_stack()'s from a few different machines over a couple weeks

Comment 2 Steve Grubb 2007-10-18 20:56:19 UTC
This issue is already being worked as bz 310651. There have been several patches
floated recently on the linux-audit mail list to solve this problem:

https://www.redhat.com/archives/linux-audit/2007-October/thread.html

I'm going to close this as a duplicate of the other bug.

Comment 3 Buck Huppmann 2007-10-19 11:20:01 UTC
thanks. i was gonna apologize for being a lousy bugzilla searcher, but it
looks like that's a private bz, so i'm going to absolve myself. please let
me know if that moves along to test kernels or anything

Comment 4 Steve Grubb 2008-04-10 15:58:30 UTC
This bug is scheduled to be fixed in 4.7 under a different bug. Closing this as
a duplicate of that bug.

*** This bug has been marked as a duplicate of 427532 ***


Note You need to log in before you can comment on or make changes to this bug.