Messages in this thread | | | Date | Wed, 28 Mar 2012 19:28:04 -0700 | From | Andrew Morton <> | Subject | Re: suppress page allocation failure warnings from sys_listxattr |
| |
On Wed, 28 Mar 2012 22:08:20 -0400 Dave Jones <davej@redhat.com> wrote:
> On Wed, Mar 28, 2012 at 07:02:11PM -0700, Andrew Morton wrote: > > > > Also, what happens if something allocates > > > and sits on a bunch of vmalloc'd memory ? would we start seeing oom kills ? > > > > vmalloc() would fail. > > Ok, that's a pretty boring failure mode, so not a big deal probably. > > > > (thinking of the context of my fuzzing tool where a bunch of instances could > > > feasibly call these syscalls and not sit on huge amounts per thread, but > > > collectively... I'm wondering if it could be provoked into killing > > > processes I don't own) > > > > umm, if you wanted to deliberately trigger a vmalloc() failure then I > > guess a good approach would be to locate a vmalloc() site which can > > persist beyond the syscall (modprobe is a good one!) then exercise it > > in a way so that there are no N-byte holes left in the arena, then > > trigger an N-byte vmalloc(). > > Well modprobe is root-only, so that's not so bad.
Even if it's root-only, we can still end up with a toasted machine. Accidentally toasted, not deliberately.
> But it looks like > key_add (see other thread from this evening) and probably others can be > called as a user and gobble up vmalloc space. omnomnom.
hm, the keys code appears to prevent the user from reserving more than 20000 bytes of memory total (key_payload_reserve()), so it doesn't look very useful for screwing up vmalloc().
| |