mtd_stresstest module bricked my dockstar

["Roland Kletzing" <devzero@web.de>]

Hello folks,
i was (really) happily fiddling  with my dockstar NAS for the last 2 days and managed to get 3.0.4 vanilla kernel running on that device, and since i wanted do do some more testing with heartbeat/led, i fired up my proven "load all sort of modules until the kernel oopses, crashes, freezes" routine (i happily ran on x86 for years as a proven source for oopsing or hanging the kernel and/or for reporting unknown bugs) and this was the last thing i saw in dmesg:
mtd_stresstest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB
 size 64
mtd_stresstest: scanning for bad eraseblocks
mtd_stresstest: scanned 8 eraseblocks, 0 are bad
mtd_stresstest: doing operations
mtd_stresstest: 0 operations done
mtd_stresstest: 1024 operations done
mtd_stresstest: 2048 operations done
.....

could not stop that, could not kill modprobe, could not unload module - device dead, no signs of life after power-cycle anymore.

DOH!

Let`s have a look:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7163cea15f7b362795b858e7c130cd617aecc0aa

ok - in there for a while.

Kconfig:

config MTD_TESTS
tristate "MTD tests support"
depends on m
help
  This option includes various MTD tests into compilation. The tests
  should normally be compiled as kernel modules. The modules perform
  various checks and verifications when loaded.


???  
"depends on m" ? 
Perform checks and verification when loaded ?
So, there is a linux kernel module which (apparently) stress-tests (i.e. overwrites) the MTD and somehow from a derived config in a third party kernel that module got it´s way into my 3.0.4 build - and on module load, it started to hammer on the first mtd it came across without any sign of warning and without any safeguard ? (i.e. the module kills your data just by loading it?)

It may be that it`s not recommended or considered "best practise" to load all sorts of unkown modules (i.e. find /lib/modules.... -name "*.ko"....)  - but people do (see https://bugzilla.novell.com/show_bug.cgi?id=224522[https://bugzilla.novell.com/show_bug.cgi?id=224522] ). And it`s not obvious that it`s THAT dangerous. And for me this is the first time Linux REALLY managed to badly brick my hardware in such a rigorous way.  Maybe someone can understand that i`m not really amused, as there is no easy way to recover, as seen on http://www.yourwarrantyisvoid.com/2010/09/08/dead-dockstar-resurrected-with-jtag/[http://www.yourwarrantyisvoid.com/2010/09/08/dead-dockstar-resurrected-with-jtag/] 

Luckily, i got that dockstar for cheap and have some more, so let`s call that "shit really happens".

I don`t want to accuse anybody, that module has it`s purpose, but please consider adding more safeguard against such issues.

One last question:
Is there any other really dangerous stuff like this inside the kernel ? (found mtd_torturetest, which seems another beast like this)

regards
Roland

ps:
Someone want the Dockstar for spending the hours and the money for debrick ? Or for extracting gold and other precious metals from electronic waste ? ;)

___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192