Bug 181795 (CVE-2006-0555) - CVE-2006-0555 NFS client panic using O_DIRECT
Summary: CVE-2006-0555 NFS client panic using O_DIRECT
Alias: CVE-2006-0555
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
Whiteboard: reported=20060215,source=vendorsec,im...
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-16 16:49 UTC by Mark J. Cox
Modified: 2018-08-15 22:44 UTC (History)
3 users (show)

Fixed In Version: RHSA-2006-0493
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-24 09:27:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
purposed patch (789 bytes, patch)
2006-04-24 13:33 UTC, Steve Dickson
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0493 normal SHIPPED_LIVE Important: kernel security update 2006-05-24 04:00:00 UTC

Description Mark J. Cox 2006-02-16 16:49:04 UTC
Mike O'Connor of SGI reported this flaw where a normal user who has access to
write to a NFS mounted fs can panic an NFS client and therefore cause a local
DoS using O_DIRECT.


Any O_DIRECT write to an NFS file where the user buffer starts
with a valid mapped page and contains an unmapped page, will
crash in this way.  I haven't followed the code, but O_DIRECT
reads with similar user buffers will probably also crash albeit
in different ways.

Details:  when nfs_get_user_pages() calls get_user_pages(), it detects
and correctly handles get_user_pages() returning an error, which happens
if the first page covered by the user buffer's address range is unmapped.
However, if the first page is mapped but some subsequent page isn't,
get_user_pages() will return a positive number which is less than the
number of pages requested (this behaviour is sort of analagous to a
short write() call and appears to be intentional).  nfs_get_user_pages()
doesn't detect this and hands off the array of pages (whose last few
elements are random rubbish from the newly allocated array memory) to
it's caller, whence they go to nfs_direct_write_seg(), which then totally
ignores the nr_pages it's given, and calculates its own idea of how many
pages are in the array from the user buffer length.  Needless to say,
when it comes to transmit those uninitialised page* pointers, we see
a crash in the network stack.

Comment 2 Mark J. Cox 2006-02-16 16:50:59 UTC
Proposed fix from Mike:

@@ -88,6 +88,15 @@ nfs_get_user_pages(int rw, unsigned long
                                        *pages, NULL);
+       BUG_ON(result > page_count);
+       /*
+        * If we got fewer pages than expected from get_user_pages(),
+        * the user buffer runs off the end of a mapping; return EFAULT.
+        */
+       if (result > 0 && result < page_count)
+               result = -EFAULT;
        return result;

Trond followed up with:

Since get_user_pages() hasn't returned an error here, I think you'll
find you also need to ensure that the pages it returned get released
correctly. Also, a result of zero pages could, AFAICS, create the same panic.

Perhaps something like the following instead?

        if (result >= 0 && result < page_count) {
                nfs_free_user_pages(*pages, result, 0);
                *pages = NULL;
                result = -EFAULT;

Comment 3 Mark J. Cox 2006-02-23 09:58:44 UTC
embargo set at 20060227:1600

Comment 4 Steve Dickson 2006-04-24 13:33:14 UTC
Created attachment 128145 [details]
purposed patch

Comment 5 Jason Baron 2006-04-26 02:43:01 UTC
committed in stream U4 build 34.24. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

Comment 10 Red Hat Bugzilla 2006-05-24 09:27:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.