[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#367125: marked as done (nfs + ext3 = possible DoS)



Your message dated Tue, 26 Sep 2006 09:48:10 -0600
with message-id <[🔎] 20060926154810.GC12302@colo>
and subject line Bug#367125: ext2_get_inode: bad inode number
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.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message --- Package: kernel-image-2.6.8-2-686-smp
Version: 2.6.8-16

Hello,

Our central nfs-server is running Debian/Sarge and there are ~300 nfs Clients running under Debian
or Solaris.  At one point we had to recreate the exported (ext3) filesystems on the server and
copy the data back from backup.  Although we rebooted most of the clients as  well, some kept running
and unforunately obviously had cached the nfs filehandles and requested the no longer
existing inodes.  This resulted in messages like this on the server:

ext3_get_inode_loc: bad inode number: 30130240

After some of these messages (cannot say the exact number) the filesystem
was mounted read-only which made it quite unusable, along with  this message:

Remounting filesystem read-only

This suprises me somewhat as with "tune2fs -e continue" the filesystem
was supposed to ignore errors.  Is that not valid for ext3 but only for ext2?
We also think that this could be used as a denial of service attack: just
request non-existing inodes and eventually the server will remount read-only.
We also observed this behaviour with linux-image-2.6.12-1-686-smp, version
2.6.12-10.  I will install linux-kernel latest version of 2.6.16 in the near future.
I'm not sure if this really is a bug but it would be great if there was a workaround.
I think it's a bug since there actually is no error in the filesystem,
there are only requests for non-existing inodes.
So how can one prevent the filesystem being remounted read-only in this
situation?

Thanks,

    Peter

--- End Message ---
--- Begin Message ---
Version: 2.6.8-16sarge5

On Tue, Sep 26, 2006 at 12:08:14PM +0200, Peter Kruse wrote:
> Hello,
> 
> it looks like that the latest security update to the kernel fixes this
> problem:

Thanks, closing therefore.

-- 
dann frazier


--- End Message ---

Reply to: