linux-kernel - Naughty ramdrives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060907205927.GA5193@martell.zuzino.mipt.ru>
Date:	Fri, 8 Sep 2006 00:59:27 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Andrew Morton <akpm@...l.org>
Subject: Naughty ramdrives

You'd laugh, but...

Summary:

	After loading and unloading rd.ko many times "ls -l /dev/ram*"
	results are not persistent.

Steps to reproduce:

	# while true; do modprobe rd && rmmod rd; done
		[wait ~10 seconds]
	^C
	# modprobe rd

	# ls -l /dev/ram*
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram12 -> rd/12
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram6 -> rd/6
	# ls -l /dev/ram*
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram0 -> rd/0
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram13 -> rd/13
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram6 -> rd/6
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram7 -> rd/7
	# ls -l /dev/ram*
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram0 -> rd/0
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram1 -> rd/1
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram11 -> rd/11
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram12 -> rd/12
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram14 -> rd/14
	lrwxrwxrwx 1 root root 5 Sep  8 00:35 /dev/ram15 -> rd/15
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram3 -> rd/3
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram7 -> rd/7
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram8 -> rd/8
	lrwxrwxrwx 1 root root 4 Sep  8 00:35 /dev/ram9 -> rd/9

Versions:

	Linux 2.6.18-rc5
	udev 087

P.S.:

This was noticed while investigating #4899
http://bugme.osdl.org/show_bug.cgi?id=4899
where /dev/ram0 when opened, pins module indefinitely. It seems that
adding ->release() which undoes

	inode = igrab(bdev->bd_inode);

should do the trick. Am I right?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/