> Alan Cox wrote:
> >
> > > Looking forward to 2.0.34 (with idt mem leak fix? This could be used as a
> > > local DoS)
> >
> > Actually you can do better than a DoS attack with it. The fix is to make
> > i_count a long at the moment.
>
> If this is being caused by excessive hard links, wouldn't it be easier
> to set some large but sane limit on the number of hard links allowed? A
> limit of 1000 or so would probably allow all legitimate uses but safely
> avoid any overflows. This would be easy to enforce in the link system
> call.
Actually, no, the originally reported problem isn't to do with hard links.
The problem is with the VFS concept of an inode, where i_count (reference
count for an inode) is 16 bits and can be overflowed by excessive
mmap()ing of single pages of a given object into your address space.
Things get nasty when you, for example, mess with libc's ref count, wrap
it to 0... but of course it is still referenced by a lot of processes. The
actual exploit then tries to replace a hacked libc into the vacated inode
slot....
Hard links (on ext2) will probably play with the on-disk inode structure
(as opposed to VFS above). Looking at the ext2 on disk inode, it's link
count is also a 16 bit value, though. Can lots of hard links to a file
wrap _this_ counter and knacker a file of your choice???? That would be 2
nasty bugs for the price of one...
Chris
PS I assume making inode->i_count a long works, because
pages in address space * max processes << 2^32 (for ix86)