ReiserFS filename hash collision causing DoS

Bug #116803 reported by David Given on 2007-05-25
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: linux-image-2.6-k7

If you create files in a directory on reiserfs, it is possible to saturate the hash table such that new files with particular filenames cannot be created.

This bug actually dates back to about 2004, but is still extant:

http://marc.info/?l=reiserfs&m=110434667931228&w=2

(The above post contains a script that demonstrates the problem which works on my Feisty system.)

This theoretically allows attackers to DoS temporary directories, etc, but does not appear to cause actual data loss. According to the originally post, this has also actually been seen in real life, although accidentally, not part of an attack.

It surprises me slightly that this bug has been around for so long, given the potential seriousness...

Kees Cook (kees) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy.

While this is an ugly bug, it can't be used to make world-writable directories less secure. Resource DoS's in temporary file areas is already possible if an attacker knows the filename being opened (which is why using mkstemp() is so important). For a hash colllision, this requirement is still true. Hitting this bug is like having another user fill up the entire /tmp partition: a user is suddenly unable to make temp files.

Please feel free to report any other bugs you may find.

Changed in linux-meta:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Andy Whitcroft (apw) wrote :

This is not a bug in the linux-meta package, moving to the linux package.

affects: linux-meta (Ubuntu) → linux (Ubuntu)
dino99 (9d9) wrote :

The problem was reported against a now too old unsupported kernel; closing that report as no recent comment have been sent.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers