From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 17 Sep 2004 17:55:14 +0400 From: "Konstantin A. Lepikhov" To: ALT Linux Kernel Devel Mailing List Message-ID: <20040917135514.GA7575@lks.home> Mail-Followup-To: ALT Linux Kernel Devel Mailing List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i X-Operation-System: ALT Linux Sisyphus (20040909) 2.6.8-wks26-up-alt3 X-Virus-Scanned: by amavisd-new at smtp.elektrostal.ru Subject: [d-kernel] PATCH: some fixes for bio_uncopy_user() leak in 2.6.8.1 X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 13:56:08 -0000 Archived-At: List-Archive: List-Post: --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Здравствуйте! Данные патчи были найдены -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 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2.6.8.1_51_bio_uncopy_user-mem-leak.patch" From: Kurt Garloff 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 Signed-off-by: Andrew Morton --- 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; } _ --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2.6.8.1_52_bio_uncopy_user2.patch" From: Chris Mason To: Con Kolivas , axboe@suse.de Cc: Greg Afinogenov , linux-kernel@vger.kernel.org, Andrew Morton , 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; } } --pf9I7BMVVzbSWLtt--