lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 13 Mar 2012 14:26:46 -0400
From:	Dave Jones <davej@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	netdev@...r.kernel.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: tun oops dereferencing garbage nsproxy-> address.

On Tue, Mar 13, 2012 at 11:19:40AM -0700, Eric W. Biederman wrote:

 > > oops happened here..
 > >
 > >         tfile->net = get_net(current->nsproxy->net_ns);
 > >      548:       48 8b 92 50 05 00 00    mov    0x550(%rdx),%rdx
 > >      54f:       48 8b 52 28             mov    0x28(%rdx),%rdx
 > >
 > > My guess is the fuzzer called some syscall that set current->nsproxy
 > > to garbage (0x0000000100000001), which later got dereferenced when it
 > > subsequently randomly did an open() on tun.
 > >
 > > Any thoughts ?
 > 
 > It smells like a memory stomp.  current->nsproxy is always supposed to
 > have a valid value, and it never would have an odd value.  The value
 > should always be at least 8 byte aligned.
 > 
 > Since the value is impossible this doesn't feel like a path where the
 > error handling is wrong.

0x0000000100000001 looks like one of strange values my fuzzer passes syscalls
when they ask for an address.

So something managed to get that set as nsproxy.  The fuzzer avoids calling
clone(), so are there other syscalls that might set this ?

 > So I am guessing this is a memory stomp.  My guess it would take the
 > same sequence of system calls on the same kernel build to reproduce
 > this problem in the same place.
 > 
 > Do you have any more information?

I've not managed to reproduce it, and that run sadly had logging turned off,
so I don't have the exact syscall sequence that caused it.

	Dave
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists