From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: akpm@linuxfoundation.org, Nick Piggin <npiggin@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
stable@kernel.org
Subject: Re: 2.6.27-rc1: IP: iov_iter_advance+0x2e/0x90
Date: Wed, 30 Jul 2008 15:02:32 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0807301500480.3277@nehalem.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0807301442130.3277@nehalem.linux-foundation.org>
On Wed, 30 Jul 2008, Linus Torvalds wrote:
>
> Ok, I'll commit it as obvious, ugly as it may be. And hope that Nick or
> some other god of iov_iter will think about trying to make these things
> more reliable and easier to use.
Oh, and I think it's stable material. Unless I misread something, this
area hasn't changed since 2.6.25. But somebody should double-check me,
that just sounds wrong.
stable added to cc, with patch appended.
Linus
---
commit 94ad374a0751f40d25e22e036c37f7263569d24c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Jul 30 14:45:12 2008 -0700
Fix off-by-one error in iov_iter_advance()
The iov_iter_advance() function would look at the iov->iov_len entry
even though it might have iterated over the whole array, and iov was
pointing past the end. This would cause DEBUG_PAGEALLOC to trigger a
kernel page fault if the allocation was at the end of a page, and the
next page was unallocated.
The quick fix is to just change the order of the tests: check that there
is any iovec data left before we check the iov entry itself.
Thanks to Alexey Dobriyan for finding this case, and testing the fix.
Reported-and-tested-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
mm/filemap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 42bbc69..d97d1ad 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1879,7 +1879,7 @@ void iov_iter_advance(struct iov_iter *i, size_t bytes)
* The !iov->iov_len check ensures we skip over unlikely
* zero-length segments (without overruning the iovec).
*/
- while (bytes || unlikely(!iov->iov_len && i->count)) {
+ while (bytes || unlikely(i->count && !iov->iov_len)) {
int copy;
copy = min(bytes, iov->iov_len - base);
next prev parent reply other threads:[~2008-07-30 22:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 19:54 Alexey Dobriyan
2008-07-30 20:09 ` Linus Torvalds
2008-07-30 21:37 ` Alexey Dobriyan
2008-07-30 21:44 ` Linus Torvalds
2008-07-30 22:02 ` Linus Torvalds [this message]
2008-07-30 22:32 ` Alexey Dobriyan
2008-07-31 2:29 ` Nick Piggin
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=alpine.LFD.1.10.0807301500480.3277@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=stable@kernel.org \
/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
all inboxes | Powered by JetHome®