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
Created attachment 231541 [details] allocation failure messages and bprm_audit frames in dump_stack()'s from a few different machines over a couple weeks
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.
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
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 ***