oss-security - CVE-2011-4325 Linux kernel: nfs: diotest4 from LTP crash client

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120206094248.GA27887@openwall.com>
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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.