Your message dated Tue, 9 May 2000 17:38:28 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#63723: hurd: suspicious code in ext2fs/pager.c
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Darren Benham
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 7 May 2000 17:00:56 +0000
Received: (qmail 25337 invoked from network); 7 May 2000 17:00:54 -0000
Received: from sunu450.rz.ruhr-uni-bochum.de (134.147.64.5)
by master.debian.org with SMTP; 7 May 2000 17:00:54 -0000
Received: (qmail 8087 invoked from network); 7 May 2000 17:01:00 -0000
Received: from dialppp-3-245.rz.ruhr-uni-bochum.de (HELO localhost)
([EMAIL PROTECTED])
by mailhost.rz.ruhr-uni-bochum.de with SMTP; 7 May 2000 17:01:00 -0000
Received: from marcus by localhost with local (Exim 3.12 #1 (Debian))
id 12oUMi-0000Sz-00; Sun, 07 May 2000 18:57:12 +0200
From: [EMAIL PROTECTED]
Subject: hurd: suspicious code in ext2fs/pager.c
To: [EMAIL PROTECTED]
X-Mailer: bug 3.2.9
Message-Id: <E12oUMi-0000Sz-00@localhost>
Date: Sun, 07 May 2000 18:57:12 +0200
Organization: Marcus Brinkmann's Home
Package: hurd
Version: N/A
Severity: normal
Hi,
again, I have no test case for this report, but only analysis of the code.
I am sure *if* it can occur, it is quite rare, so it's not urgent.
In ext2fs/pager.c (diskfs_grow), it seems that a file could shrink by one
block. Assume new_end_block > end_block, and
dn->last_page_partially_writable, and old_page_end_block > end_block,
AND diskfs_catch_exceptions fails (this is a rather strong assumption, I
don't know under which circumstances it might happen).
err = diskfs_catch_exception ();
while (!err && end_block < writable_end)
{
block_t disk_block;
err = ext2_getblk (node, end_block++, 1, &disk_block);
}
diskfs_end_catch_exception ();
if (err)
/* Reflect how much we allocated successfully. */
new_size = (end_block - 1) << log2_block_size;
The while loop is not entered, because of ERR. This means that end_block is
still old_size >> log2_block_size. So, because ERR is true, new_size is set to
(end_block - 1) << log2_block_size
== ((old_size >> log2_block_size) - 1) << log2_block_size
== old_size - block_size
(or something worse if old_size < block_size and an underrun occurred).
The "- 1", which is meant to take care of the additional end_block++ in the
body of the while loop, is harmful here.
Thanks,
Marcus
-- System Information
Debian Release: woody
Kernel Version: Linux ulysses 2.2.12 #7 Mon Sep 27 01:09:52 CEST 1999 i586 unknown
---------------------------------------
Received: (at 63723-done) by bugs.debian.org; 9 May 2000 15:40:00 +0000
>From [EMAIL PROTECTED] Tue May 09 10:40:00 2000
Received: from sunu450.rz.ruhr-uni-bochum.de [134.147.64.5]
by master.debian.org with smtp (Exim 3.12 #2 (Debian))
id 12pC75-0003kp-00; Tue, 09 May 2000 10:40:00 -0500
Received: (qmail 10021 invoked from network); 9 May 2000 15:40:02 -0000
Received: from dialppp-7-85.rz.ruhr-uni-bochum.de (HELO localhost) ([EMAIL PROTECTED])
by mailhost.rz.ruhr-uni-bochum.de with SMTP; 9 May 2000 15:40:02 -0000
Received: from marcus by localhost with local (Exim 3.12 #1 (Debian))
id 12pC5c-0000VS-00; Tue, 09 May 2000 17:38:29 +0200
Date: Tue, 9 May 2000 17:38:28 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#63723: hurd: suspicious code in ext2fs/pager.c
Message-ID: <[EMAIL PROTECTED]>
References: <E12oUMi-0000Sz-00@localhost> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.4i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon,
May 08, 2000 at 08:52:04AM +0300
Organization: Marcus Brinkmann's Home
On Mon, May 08, 2000 at 08:52:04AM +0300, Kalle Olavi Niemitalo wrote:
> [EMAIL PROTECTED] writes:
>
> > AND diskfs_catch_exceptions fails (this is a rather strong assumption, I
> > don't know under which circumstances it might happen).
>
> diskfs_catch_exception takes its return value from setjmp() so it
> can't fail when it first returns.
>
> It can return a nonzero value later if there's a fault between
> diskfs_catch_exception and diskfs_end_catch_exception. It seems
> the fault could only happen in ext2_getblk. When that is called,
> end_block has already been incremented. So the code is safe.
You are right. The positive side effect is that I now understand how
diskfs_catch_exception works and what setjmp/longjmp means (it's the first
time I encounter them).
It would be nice to have those macros documented in hurd.info, though.
Thanks!
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
