Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Feb 2012 13:42:48 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2011-4325 Linux kernel: nfs: diotest4 from LTP crash client

Hi,

I could not find this one on oss-security.

http://rhn.redhat.com/errata/RHSA-2012-0007.html says "A flaw was found
in the Linux kernel's NFS implementation. A local, unprivileged user
could use this flaw to cause a denial of service.  (CVE-2011-4325,
Moderate)"

https://bugzilla.redhat.com/show_bug.cgi?id=755455 mentions "null
pointer deref" in its title and says "diotest4 from LTP will crash
client on NFS mount. Not a regression, 5.7 GA kernel has the same
issue."  It refers to:

Upstream commit:
http://git.kernel.org/linus/1ae88b2e4 (v2.6.31-rc6)

The commit message:

"We can't call nfs_readdata_release()/nfs_writedata_release() without
first initialising and referencing args.context. Doing so inside
nfs_direct_read_schedule_segment()/nfs_direct_write_schedule_segment()
causes an Oops.

We should rather be calling nfs_readdata_free()/nfs_writedata_free() in
those cases.

Looking at the O_DIRECT code, the "struct nfs_direct_req" is already
referencing the nfs_open_context for us. Since the readdata and writedata
structures carry a reference to that, we can simplify things by getting rid
of the extra nfs_open_context references, so that we can replace all
instances of nfs_readdata_release()/nfs_writedata_release()."

I was able to find this on LKML, but with no more detail:

http://lists.openwall.net/linux-kernel/2009/08/12/215

Apparently, an uninitialized pointer was being accessed, and apparently
it happened to be NULL (or nearby) on some occasion - but I see no proof
that it would always be NULL, although there may well be something that
makes it so.

Overall, after a quick glance at the fix, I am not convinced that this
was just a DoS.  Someone familiar with the code might have a better idea.

Also, does Red Hat treat NULL pointer derefs in the kernel as DoS only
now, relying primarily on mmap_min_addr to work?  (We do.  And we'll
treat a mmap_min_addr bypass if another one of these is found, as the
real privilege escalation issue, assuming that plenty of NULL derefs
exist in the kernel.)

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ