All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: Roland McGrath <roland@redhat.com>
Cc: Kees Cook <kees.cook@canonical.com>,
	linux-kernel@vger.kernel.org, oss-security@lists.openwall.com,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] exec argument expansion can inappropriately trigger OOM-killer
Date: Mon, 30 Aug 2010 21:49:20 +0400	[thread overview]
Message-ID: <20100830174920.GA25091@openwall.com> (raw)
In-Reply-To: <20100830032331.GA22773@openwall.com>

On Mon, Aug 30, 2010 at 07:23:31AM +0400, Solar Designer wrote:
> Additionally, 64bit_dos.c mentions that "it triggers a BUG() as the
> stack tries to expand around the address space when shifted".
[...]
> which is likely part of a fix (but not the entire fix) for what the
> comment in 64bit_dos.c refers to.  However, I was not able to trigger
> the BUG_ON() on RHEL5'ish kernels by simply running the 64bit_dos
> program (64-bit to 32-bit exec) on two systems, one with 2 GB RAM, the
> other with 4 GB.  Of course, I set "ulimit -s unlimited" first.

I am finally able to trigger the BUG by replacing "/bin/sh" with
"/bin/false" in 64bit_dos.c, relying on our library-free implementation
of /bin/false on Owl:

owl!solar:~$ objdump -d /bin/false

/bin/false:     file format elf32-i386

Disassembly of section .text:

08048074 <.text>:
 8048074:       b8 01 00 00 00          mov    $0x1,%eax
 8048079:       bb 01 00 00 00          mov    $0x1,%ebx
 804807e:       cd 80                   int    $0x80

owl!solar:~$ file 64bit_dos
64bit_dos: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, statically linked, for GNU/Linux 2.4.0, stripped

(the "exploit" is statically-linked since I brought it from another
machine, I don't think this matters).

After looping in the kernel for about 10 seconds, I got:

Kernel BUG at fs/exec.c:535
[...]
Call Trace:
 [<ffffffff8007c44c>] load_elf32_binary+0x7f9/0x1702
 [<ffffffff800c193f>] expand_stack+0x7f/0xad
 [<ffffffff8003e39b>] search_binary_handler+0x94/0x1e2
 [<ffffffff8003da2f>] do_execve+0x18e/0x1f2
 [<ffffffff800542cc>] sys_execve+0x34/0x51
 [<ffffffff8005e523>] stub_execve+0x67/0xb0
[...]
Code: 0f 0b 68 fe 93 3e 80 c2 17 02 48 8b 7c 24 08 4c 89 fe e8 da 
RIP  [<ffffffff8002dc90>] setup_arg_pages+0x151/0x2d3

The kernel is a revision and custom build of 2.6.18-128.2.1.el5
(whatever I happened to readily have installed on a test system).
I think the problem should be reproducible with current RHEL5 kernels
and likely with latest mainstream kernels as well.

The process is stuck:

solar    28754  2.8 77.8 3142276 3142276 pts/0 D+   10:34   0:13 [false]

(uninterruptible)

3 GB memory is still taken.

Alexander

WARNING: multiple messages have this Message-ID (diff)
From: Solar Designer <solar-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
To: Roland McGrath <roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Kees Cook <kees.cook-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	oss-security-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	KOSAKI Motohiro
	<kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] exec argument expansion can inappropriately trigger OOM-killer
Date: Mon, 30 Aug 2010 21:49:20 +0400	[thread overview]
Message-ID: <20100830174920.GA25091@openwall.com> (raw)
In-Reply-To: <20100830032331.GA22773-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>

On Mon, Aug 30, 2010 at 07:23:31AM +0400, Solar Designer wrote:
> Additionally, 64bit_dos.c mentions that "it triggers a BUG() as the
> stack tries to expand around the address space when shifted".
[...]
> which is likely part of a fix (but not the entire fix) for what the
> comment in 64bit_dos.c refers to.  However, I was not able to trigger
> the BUG_ON() on RHEL5'ish kernels by simply running the 64bit_dos
> program (64-bit to 32-bit exec) on two systems, one with 2 GB RAM, the
> other with 4 GB.  Of course, I set "ulimit -s unlimited" first.

I am finally able to trigger the BUG by replacing "/bin/sh" with
"/bin/false" in 64bit_dos.c, relying on our library-free implementation
of /bin/false on Owl:

owl!solar:~$ objdump -d /bin/false

/bin/false:     file format elf32-i386

Disassembly of section .text:

08048074 <.text>:
 8048074:       b8 01 00 00 00          mov    $0x1,%eax
 8048079:       bb 01 00 00 00          mov    $0x1,%ebx
 804807e:       cd 80                   int    $0x80

owl!solar:~$ file 64bit_dos
64bit_dos: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, statically linked, for GNU/Linux 2.4.0, stripped

(the "exploit" is statically-linked since I brought it from another
machine, I don't think this matters).

After looping in the kernel for about 10 seconds, I got:

Kernel BUG at fs/exec.c:535
[...]
Call Trace:
 [<ffffffff8007c44c>] load_elf32_binary+0x7f9/0x1702
 [<ffffffff800c193f>] expand_stack+0x7f/0xad
 [<ffffffff8003e39b>] search_binary_handler+0x94/0x1e2
 [<ffffffff8003da2f>] do_execve+0x18e/0x1f2
 [<ffffffff800542cc>] sys_execve+0x34/0x51
 [<ffffffff8005e523>] stub_execve+0x67/0xb0
[...]
Code: 0f 0b 68 fe 93 3e 80 c2 17 02 48 8b 7c 24 08 4c 89 fe e8 da 
RIP  [<ffffffff8002dc90>] setup_arg_pages+0x151/0x2d3

The kernel is a revision and custom build of 2.6.18-128.2.1.el5
(whatever I happened to readily have installed on a test system).
I think the problem should be reproducible with current RHEL5 kernels
and likely with latest mainstream kernels as well.

The process is stuck:

solar    28754  2.8 77.8 3142276 3142276 pts/0 D+   10:34   0:13 [false]

(uninterruptible)

3 GB memory is still taken.

Alexander

  parent reply	other threads:[~2010-08-30 17:49 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-27 22:02 [PATCH] exec argument expansion can inappropriately trigger OOM-killer Kees Cook
2010-08-30  0:19 ` KOSAKI Motohiro
2010-08-30  0:56 ` Roland McGrath
2010-08-30  3:23   ` Solar Designer
2010-08-30  3:23     ` Solar Designer
2010-08-30 10:06     ` Roland McGrath
2010-08-30 19:48       ` Solar Designer
2010-08-31  0:40         ` Roland McGrath
2010-09-08  2:34       ` [PATCH 0/3] execve argument-copying fixes Roland McGrath
2010-09-08  2:35         ` [PATCH 1/3] setup_arg_pages: diagnose excessive argument size Roland McGrath
2010-09-08  8:29           ` pageexec
2010-09-10  8:59             ` Roland McGrath
2010-09-10  8:59               ` Roland McGrath
2010-09-11 13:30               ` pageexec
2010-09-11 13:30                 ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-14 19:33                 ` Roland McGrath
2010-09-14 22:35                   ` pageexec
2010-09-14 22:35                     ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-08 11:57           ` Brad Spengler
2010-09-09  5:31             ` KOSAKI Motohiro
2010-09-10  9:25               ` Roland McGrath
2010-09-10  9:25                 ` Roland McGrath
2010-09-10  9:43                 ` KOSAKI Motohiro
2010-09-11 13:39                 ` pageexec
2010-09-11 13:39                   ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-14 18:51                   ` Roland McGrath
2010-09-14 18:51                     ` Roland McGrath
2010-09-14 20:28                     ` pageexec
2010-09-14 20:28                       ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-14 21:16                       ` Roland McGrath
2010-09-14 21:16                         ` Roland McGrath
2010-09-14 22:27                         ` pageexec
2010-09-14 22:27                           ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-14 23:04                           ` Roland McGrath
2010-09-14 23:04                             ` Roland McGrath
2010-09-15  9:27                             ` pageexec
2010-09-15  9:27                               ` pageexec-Y8qEzhMunLyT9ig0jae3mg
2010-09-10  9:18             ` Roland McGrath
2010-09-10  9:18               ` Roland McGrath
2010-09-08  2:36         ` [PATCH 2/3] execve: improve interactivity with large arguments Roland McGrath
2010-09-08  2:37         ` [PATCH 3/3] execve: make responsive to SIGKILL " Roland McGrath
2010-09-08  3:00         ` [PATCH 0/3] execve argument-copying fixes KOSAKI Motohiro
2010-09-09  5:01         ` [PATCH 0/2] execve memory exhaust of " KOSAKI Motohiro
2010-09-09  5:03           ` [PATCH 1/2] oom: don't ignore rss in nascent mm KOSAKI Motohiro
2010-09-09 22:05             ` Oleg Nesterov
2010-09-10  9:39               ` Roland McGrath
2010-09-10  9:39                 ` Roland McGrath
2010-09-10  9:57               ` [PATCH] move cred_guard_mutex from task_struct to signal_struct KOSAKI Motohiro
2010-09-10 17:24                 ` Oleg Nesterov
2010-09-16  5:51                   ` KOSAKI Motohiro
2010-09-09  5:04           ` [PATCH 2/2] execve: check the VM has enough memory at first KOSAKI Motohiro
2010-09-10 15:06             ` Linus Torvalds
2010-09-14  1:52               ` KOSAKI Motohiro
2010-09-16  5:51                 ` KOSAKI Motohiro
2010-09-16 15:01                   ` Linus Torvalds
2010-08-30 17:49     ` Solar Designer [this message]
2010-08-30 17:49       ` [PATCH] exec argument expansion can inappropriately trigger OOM-killer Solar Designer
2010-08-30 22:08       ` Brad Spengler
2010-08-30 22:08         ` Brad Spengler
2010-08-31 11:53         ` Solar Designer
2010-08-31 11:53           ` Solar Designer
2010-08-31 11:56         ` [PATCH] exec argument expansion can inappropriately triggerOOM-killer Tetsuo Handa

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20100830174920.GA25091@openwall.com \
    --to=solar@openwall.com \
    --cc=akpm@linux-foundation.org \
    --cc=kees.cook@canonical.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=oleg@redhat.com \
    --cc=oss-security@lists.openwall.com \
    --cc=roland@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.