Description of Problem:
I've found an apparent local (or possibly remote) DoS that is 
due to a bug somewhere in Reiserfs apparently.  Kernel version is stock RedHat 2.4.13smp.  
Root fs is EXT3.  File system in question is a secondary storage fs that is software RAID0 
over hardware RAID5 on 3ware cards.  Reiserfs partition is created on 
/dev/md0.

Attempting to create a file on the Reiser partition that is larger than 2GB 
will cause the process that is accessing that file to continue to write, but the file size 
as reported by df and ls maxes out at 2GB.  Once the process starts attempting to write past 
2GB, it cannot be killed.  This means an unprivlidged user can create many processes that 
cannot be killed by any means, except for a hardware reset of the system.  Reboot is 
impossible, as the processes will not die.  Attempts to rm this file will cause rm to hang 
with high cpu usage.  The filesystem with the large file on it must be destroyed to get rid of 
the file.

This could be a remote DoS in certain configurations.  IPCHAINS rules that log 
invalid packets, or similar logging with any remote application could be used to attempt 
to create large log files that would hang system, force hard boot, and damage filesystem.  
Workaround would be to ensure that all logs cannot exceed 2GB under any circumstances, if 
they are written to Reiserfs.

Version-Release number of selected component (if 
applicable):
2.4.9-13smp #1 SMP Tue Oct 30 19:57:16 EST 2001 i686 unknown

How 
Reproducible:
Always, on system in question.  Was not able to get access to other systems 
with reiserfs to confirm.  Confirmed that EXT3 has no problem with big files in default Red 
Hat config.

Steps to Reproduce:
Create large reiserfs filesystem on 2.4.9-13smp
dd 
if=/dev/zero of=/storage/bigfile
Wait until file hits 2GB
Attempt to kill dd process 
or rm file.

Actual Results:
Hung processes with high cpu use, that cannot be killed by 
owner or root.
System must be hard booted, file system must be recreated.

Expected 
Results:
A big file of NULLs

Additional Information:
Contacted 3ware driver 
maintainer, he said problem was not with driver, and likely not with software RAID0 code, 
as those operate on the block level and are not aware of file sizes.  He suggested the file 
system as a likely culprit.

System is Red Hat 7.2 with all updates applied.