All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.