linux-kernel - Re: race in sysfs between sysfs_remove

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Dec 2006 11:06:41 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Maneesh Soni <maneesh@...ibm.com>
cc:	Oliver Neukum <oliver@...kum.org>, <gregkh@...e.com>,
	<linux-usb-devel@...ts.sourceforge.net>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: race in sysfs between sysfs_remove_file() and read()/write() #2

On Mon, 4 Dec 2006, Maneesh Soni wrote:

> hmm, I guess Greg has to say the final word. The question is either to fail
> the IO (-ENODEV) or fail the file removal (-EBUSY). If we are not going to
> fail the removal then your patch is the way to go.
> 
> Greg?

Oliver is right that we cannot allow device_remove_file() to fail.  In 
fact we can't even allow it to block until all the existing open file 
references are closed.

Our major questions have to do with the details of the patch itself.  In 
particular, we are worried about possible races with the VFS and the 
handling of the inode's usage count.  Can you examine the patch carefully 
to see if it is okay?

Also, Oliver, it looks like the latest version of your patch makes an 
unnecessary change to sysfs_remove_file().

Alan Stern

-
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/