LKML Archive on
help / color / mirror / Atom feed
From: Stas Sergeev <>
Subject: Bug in VM accounting code, probably exploitable
Date: Tue, 11 May 2004 23:50:27 +0400	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]


As far as I know, if overcommit is
disabled, the OOM kill should never
It seems to be the bug in the linux
kernel though (any version I think,
probably also including 2.4.x), which
makes it possible to overcommit almost
arbitrary and provoke an OOM kill
Attached is a program that demonstrates
the bug. Don't forget to "swapoff -a"
before starting it, or touching pages
will take eternity. And the amount of
RAM must be <1Gb, or the prog will not

On 2.4.25 I get:
May 11 22:28:18 lin kernel: __alloc_pages: 0-order allocation failed 
May 11 22:28:20 lin syslogd: /var/log/debug: Cannot allocate memory
May 11 22:28:18 lin kernel: VM: killing process mozilla-bin
May 11 22:28:18 lin kernel: __alloc_pages: 0-order allocation failed 
May 11 22:28:20 lin kernel: __alloc_pages: 0-order allocation failed 
May 11 22:28:21 lin kernel: __alloc_pages: 0-order allocation failed 
May 11 22:28:21 lin kernel: VM: killing process X
May 11 22:28:21 lin gnome-name-server[1254]: input condition is: 0x11, 
May 11 22:29:00 lin kernel: __alloc_pages: 0-order allocation failed 
May 11 22:29:00 lin kernel: VM: killing process overc_test
As you can see, the program caused many
other processes to be killed, before it
died itself.

2.6.6 seems to kill only the test
program itself, but there is one
nasty side-effect here, that mprotect()
fails to merge VMAs because one VMA can
end up with VM_ACCOUNT flag set, and
another - without that flag. That makes
several apps of mine to malfuncate.
Also it might be possible to bypass the
security_vm_enough_memory() checks, which
may probably be exploitable in some other

I am also attaching the fix for 2.6

Would be nice if someone can confirm
the bug and verify the fix. Perhaps
I am missing something obvious here,
at least the fact that both 2.6 and 2.4
behaves similar, confuses me. And the
fix looks also very strange, but it
seems to work.

[-- Attachment #2: overc_test.c --]
[-- Type: text/plain, Size: 964 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <asm/page.h>
#include <errno.h>

#define SIZE (1024 * 1024 * 1024)

int main(int argc, char *argv[])
  char *addr;
  int i;

  if ((addr = mmap(0, SIZE, PROT_READ | PROT_WRITE,
    printf("You have more than %i memory, increase SIZE\n", SIZE);
    return 1;
  printf("OK, now trying uncommited...\n");
  if ((addr = mmap(0, SIZE, PROT_NONE,
    return 1;
  if (mprotect(addr, SIZE, PROT_READ | PROT_WRITE) == -1) {
    return 1;

  printf("Memory of size %i successfully committed!\n", SIZE);
  printf("overcommit_memory: ");
  system("cat /proc/sys/vm/overcommit_memory");

  for (i = 0; i < SIZE; i += PAGE_SIZE) {
    addr[i] = 1;

  return 0;

[-- Attachment #3: vm_acct.diff --]
[-- Type: text/plain, Size: 517 bytes --]

--- linux/include/linux/mm.h	2004-04-14 09:41:36.000000000 +0400
+++ linux/include/linux/mm.h	2004-05-11 15:29:00.447968384 +0400
@@ -126,7 +126,7 @@
 #define VM_NONLINEAR	0x00800000	/* Is non-linear (remap_file_pages) */
 /* It makes sense to apply VM_ACCOUNT to this vma. */
-#define VM_MAYACCT(vma) (!!((vma)->vm_flags & VM_HUGETLB))
+#define VM_MAYACCT(vma) (!((vma)->vm_flags & VM_HUGETLB))
 #ifndef VM_STACK_DEFAULT_FLAGS		/* arch can override this */

[-- Attachment #4: Type: text/plain, Size: 82 bytes --]

Scanned by evaluation version of Dr.Web antivirus Daemon

             reply	other threads:[~2004-05-11 19:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-11 19:50 Stas Sergeev [this message]
2004-05-11 20:45 ` Hugh Dickins
2004-05-20 19:43 ` Marcelo Tosatti
2004-05-22 12:46   ` Stas Sergeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: Bug in VM accounting code, probably exploitable' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).