public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Dave Jones <davej@redhat.com>,
	Chuck Wolber <chuckw@quantumlinux.com>,
	Chris Wedgwood <reviews@ml.cw.f00f.org>,
	Michael Krufky <mkrufky@linuxtv.org>,
	Chuck Ebbert <cebbert@redhat.com>,
	Domenico Andreoli <cavokz@gmail.com>,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	alan@lxorguk.ukuu.org.uk, Jonathan Corbet <corbet@lwn.net>
Subject: [patch 7/8] Be more robust about bad arguments in get_user_pages()
Date: Fri, 22 Feb 2008 16:17:36 -0800	[thread overview]
Message-ID: <20080223001736.GH27727@suse.de> (raw)
In-Reply-To: <20080223001702.GA27727@suse.de>

[-- Attachment #1: be-more-robust-about-bad-arguments-in-get_user_pages.patch --]
[-- Type: text/plain, Size: 1723 bytes --]

2.6.23-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Jonathan Corbet <corbet@lwn.net>

patch 900cf086fd2fbad07f72f4575449e0d0958f860f in mainline.

So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns out that it's a buffer
overflow problem which is made easy by the way get_user_pages() is
coded.

In particular, "len" is a signed int, and it is only checked at the
*end* of a do {} while() loop.  So, if it is passed in as zero, the loop
will execute once and decrement len to -1.  At that point, the loop will
proceed until the next invalid address is found; in the process, it will
likely overflow the pages array passed in to get_user_pages().

I think that, if get_user_pages() has been asked to grab zero pages,
that's what it should do.  Thus this patch; it is, among other things,
enough to block the (already fixed) root exploit and any others which
might be lurking in similar code.  I also think that the number of pages
should be unsigned, but changing the prototype of this function probably
requires some more careful review.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/memory.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -981,6 +981,8 @@ int get_user_pages(struct task_struct *t
 	int i;
 	unsigned int vm_flags;
 
+	if (len <= 0)
+		return 0;
 	/* 
 	 * Require read or write permissions.
 	 * If 'force' is set, we only require the "MAY" flags.

-- 

  parent reply	other threads:[~2008-02-23  0:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080223001123.939868182@mini.kroah.org>
2008-02-23  0:17 ` [patch 0/8] 2.6.23-stable review Greg KH
2008-02-23  0:17   ` [patch 1/8] SCSI: sd: handle bad lba in sense information Greg KH
2008-02-23  0:17   ` [patch 2/8] NFS: Fix a potential file corruption issue when writing Greg KH
2008-02-23  0:17   ` [patch 3/8] NETFILTER: nf_conntrack_tcp: conntrack reopening fix Greg KH
2008-02-23  0:17   ` [patch 4/8] hrtimer: check relative timeouts for overflow Greg KH
2008-02-23  0:17   ` [patch 5/8] genirq: do not leave interupts enabled on free_irq Greg KH
2008-02-23  0:17   ` [patch 6/8] Disable G5 NAP mode during SMU commands on U3 Greg KH
2008-02-23  0:17   ` Greg KH [this message]
2008-02-23  0:17   ` [patch 8/8] x86_64: CPA, fix cache attribute inconsistency bug Greg KH
2008-02-23 16:55   ` [patch 0/8] 2.6.23-stable review Chuck Ebbert

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=20080223001736.GH27727@suse.de \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cavokz@gmail.com \
    --cc=cebbert@redhat.com \
    --cc=chuckw@quantumlinux.com \
    --cc=corbet@lwn.net \
    --cc=davej@redhat.com \
    --cc=jmforbes@linuxtx.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    --cc=rdunlap@xenotime.net \
    --cc=reviews@ml.cw.f00f.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=zwane@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox