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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Jan 2012 00:32:54 +0100 From: Jan Kara <jack@...e.cz> To: Andreas Dilger <adilger.kernel@...ger.ca> Cc: Djalal Harouni <tixxdz@...ndz.org>, Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>, "Darrick J. Wong" <djwong@...ibm.com>, Theodore Ts'o <tytso@....edu>, Yongqiang Yang <xiaoqiangnk@...il.com>, ext4 development <linux-ext4@...r.kernel.org>, linux-kernel Mailing List <linux-kernel@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk> Subject: Re: [PATCH] fs/ext{3,4}: fix potential race when setversion ioctl updates inode On Wed 04-01-12 16:15:04, Andreas Dilger wrote: > On 2012-01-04, at 10:46 AM, Jan Kara wrote: > > On Tue 03-01-12 02:31:52, Djalal Harouni wrote: > >> > >> The EXT{3,4}_IOC_SETVERSION ioctl() updates the inode without i_mutex, > >> this can lead to a race with the other operations that update the same > >> inode. > >> > >> Patch tested. > > > > OK, so I've taken the patch into my tree, just updated the changelog > > which result of our discussion in this thread. I also took the ext4 part > > since there is no risk of conflict and the patch looks obvious. > > Actually, I'd like to hear more about whether this is a real problem, or > if it is just a theoretical problem found during code inspection or from > some static code analysis tool? As far as I understood that was just a theoretical issue and I applied the patch just on the grounds that it is more consistent to use i_mutex for i_generation changes. > With the metadata checksum feature we were discussing using the inode > generation as part of the seed for the directory leaf block checksum, so > that it wasn't possible to incorrectly access stale directory blocks from > a previous incarnation of the same inode number. > > We were discussing just disabling this ioctl on filesystems with metadata > checksums, and printing a deprecation warning for filesystems without that > feature enabled. I'm not aware of any real-world use for this ioctl, since > NFS cannot use it to reconstruct handles because there's no API to allocate > an inode with a specific number, so setting the generation is pointless. OK, I didn't know this. I'm fine with deprecating the ioctl if it's useless but since that's going to take a while I think the cleanup still makes some sense. Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists