Bug 338761 - execve() fails with ENOMEM with not-too-huge argv[][] b/c of auditing demands
execve() fails with ENOMEM with not-too-huge argv[][] b/c of auditing demands
Status: CLOSED DUPLICATE of bug 427532
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audit (Show other bugs)
4.5
All Linux
low Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-18 16:26 EDT by Buck Huppmann
Modified: 2008-04-10 11:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-10 11:58:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 16:26 EDT, Buck Huppmann
no flags Details

  None (edit)
Description Buck Huppmann 2007-10-18 16:26:03 EDT
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 16:26:03 EDT
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 16:56:19 EDT
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 07:20:01 EDT
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 11:58:30 EDT
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.