From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [PATCH V3] limit minixfs printks on corrupted dir i_size, CVE-2006-6058 Date: Wed, 15 Aug 2007 09:59:34 -0500 Message-ID: <46C314D6.6090402@redhat.com> References: <8Qlff-3jX-29@gated-at.bofh.it> <8Qn7m-6li-27@gated-at.bofh.it> <46C09AE0.5010902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-kernel Mailing List , linux-fsdevel , security@kernel.org To: Bodo Eggert <7eggert@gmx.de> Return-path: Received: from mx1.redhat.com ([66.187.233.31]:58498 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755733AbXHOO7m (ORCPT ); Wed, 15 Aug 2007 10:59:42 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bodo Eggert wrote: >> Ok, do you like this slightly better? It states the subsystem, the >> function with the error, the block nr. in the case of a too-large block, >> and the block device on which the error occurred. > > - how long is BDEVNAME_SIZE? Will it fit on the stack? #define BDEVNAME_SIZE 32 /* Largest string for a blockdev identifier */ ~60 other users in md, ext3, jbd, buffer.c, etc. place it on the stack... > - Does it include thespace for \0? bdevname calls disk_name which does snprintf(buf, BDEVNAME_SIZE, ...), so yes. -Eric > I asume you copied other users, and the other users will do it right (or > at least not terribly wrong:), but I can't dig the code right now. > >> Honestly minix.fsck >> doesn't handle the situation well either, so at this point I hesitate >> to recommend it in the print. :) > > *g*