[d-kernel] PATCH: some fixes for bio_uncopy_user() leak in 2.6.8.1

Konstantin A. Lepikhov lakostis at anti-leasure.ru
Fri Sep 17 17:55:14 MSD 2004


Здравствуйте!

Данные патчи были найдены -ck7. Есть ли смысл их добавить в fix-fs
(fix-security)? 

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis �� jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis �� pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR
----------- следущая часть -----------

From: Kurt Garloff <garloff �� suse.de>

When using bounce buffers for SG_IO commands with unaligned buffers in
blk_rq_map_user(), we should free the pages from blk_rq_unmap_user() which
calls bio_uncopy_user() for the non-BIO_USER_MAPPED case.  That function
failed to free the pages for write requests.

So we leaked pages and you machine would go OOM.  Rebooting helped ;-)

This bug was triggered by writing audio CDs (but not on data CDs), as the
audio frames are not aligned well (2352 bytes), so the user pages don't
just get mapped.

Bug was reported by Mathias Homan and debugged by Chris Mason + me.  (Jens
is away.)

Signed-off-by: Kurt Garloff <garloff �� suse.de>
Signed-off-by: Andrew Morton <akpm �� osdl.org>
---

 25-akpm/fs/bio.c |   19 ++++++++-----------
 1 files changed, 8 insertions(+), 11 deletions(-)

diff -puN fs/bio.c~bio_uncopy_user-mem-leak fs/bio.c
--- 25/fs/bio.c~bio_uncopy_user-mem-leak	Tue Aug 17 15:46:53 2004
+++ 25-akpm/fs/bio.c	Tue Aug 17 15:46:53 2004
@@ -388,20 +388,17 @@ int bio_uncopy_user(struct bio *bio)
 	struct bio_vec *bvec;
 	int i, ret = 0;
 
-	if (bio_data_dir(bio) == READ) {
-		char *uaddr = bio->bi_private;
+	char *uaddr = bio->bi_private;
 
-		__bio_for_each_segment(bvec, bio, i, 0) {
-			char *addr = page_address(bvec->bv_page);
+	__bio_for_each_segment(bvec, bio, i, 0) {
+		char *addr = page_address(bvec->bv_page);
+		if (bio_data_dir(bio) == READ && !ret &&
+		    copy_to_user(uaddr, addr, bvec->bv_len))
+			ret = -EFAULT;
 
-			if (!ret && copy_to_user(uaddr, addr, bvec->bv_len))
-				ret = -EFAULT;
-
-			__free_page(bvec->bv_page);
-			uaddr += bvec->bv_len;
-		}
+		__free_page(bvec->bv_page);
+		uaddr += bvec->bv_len;
 	}
-
 	bio_put(bio);
 	return ret;
 }
_
----------- следущая часть -----------
From: Chris Mason <mason �� suse.com>
To: Con Kolivas <kernel �� kolivas.org>, axboe �� suse.de
Cc: Greg Afinogenov <antisthenes �� inbox.ru>,
	linux-kernel �� vger.kernel.org, Andrew Morton <akpm �� osdl.org>,
	garloff �� suse.de
In-Reply-To: <412489E5.7000806 �� kolivas.org>
References: <1092909598.8364.5.camel �� localhost>
	 <412489E5.7000806 �� kolivas.org>
Content-Type: text/plain
Message-Id: <1092923494.12138.1667.camel �� watt.suse.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 19 Aug 2004 09:51:34 -0400
Content-Transfer-Encoding: 7bit

On Thu, 2004-08-19 at 07:07, Con Kolivas wrote:
> Greg Afinogenov wrote:
> > I'd just like to point out that this patch does not, as may be expected,
> > result in functional audio CDs.  It merely results in a successful burn
> > process and a CD full of noise.
> > 
> > Perhaps this should be tested/fixed?
> 
> Ok I just tested this patch discretely and indeed the memory leak goes 
> away but it still produces coasters so something is still amuck. Just as 
> a data point; burning DVDs and data cds is ok. Burning audio *and 
> videocds* is not.

It might be the cold medicine talking, but I think we need something
like this.  gcc tested it for me, beyond that I make no promises....

--- l/fs/bio.c.1	2004-08-19 09:36:13.596858736 -0400
+++ l/fs/bio.c	2004-08-19 09:47:46.392537784 -0400
@@ -454,6 +454,7 @@
 	 */
 	if (!ret) {
 		if (!write_to_vm) {
+			unsigned long p = uaddr;
 			bio->bi_rw |= (1 << BIO_RW);
 			/*
 	 		 * for a write, copy in data to kernel pages
@@ -462,8 +463,9 @@
 			bio_for_each_segment(bvec, bio, i) {
 				char *addr = page_address(bvec->bv_page);
 
-				if (copy_from_user(addr, (char *) uaddr, bvec->bv_len))
+				if (copy_from_user(addr, (char *) p, bvec->bv_len))
 					goto cleanup;
+				p += bvec->bv_len;
 			}
 		}
 






More information about the devel-kernel mailing list