ReiserFS filename hash collision causing DoS
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Ubuntu) |
Invalid
|
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://
(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 | #1 |
| Changed in linux-meta: | |
| importance: | Undecided → Low |
| status: | Unconfirmed → Confirmed |
| Andy Whitcroft (apw) wrote | #2 |
| affects: | linux-meta (Ubuntu) → linux (Ubuntu) |
| dino99 (9d9) wrote | #3 |
| Changed in linux (Ubuntu): | |
| status: | Confirmed → Invalid |
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.