On Fri, May 18, 2018 at 5:11 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Fri, May 18, 2018 at 5:03 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> On Fri, May 18, 2018 at 11:29:37AM +0300, Amir Goldstein wrote: >>> Currently, there is a small window where ovl_obtain_alias() can >>> race with ovl_instantiate() and create two different overlay inodes >>> with the same underlying real non-dir non-hardlink inode. >>> >>> The race requires an adversary to guess the file handle of the >>> yet to be created upper inode and decode the guessed file handle >>> after ovl_creat_real(), but before ovl_instantiate(). >>> This race does not affect overlay directory inodes, because those >>> are decoded via ovl_lookup_real() and not with ovl_obtain_alias(). >>> >>> This patch fixes the race, by using iget5_prealloc() to add a newly >>> created inode to cache. >> >> Mind explaining what the hell is wrong with insert_inode_locked4()? > > That it doesn't return the old inode if found. > > Btw, these functions are eerily similar, and it'd be nice to reduce > the number of them. Does inode_sb_list_add() need inode_hash_lock? I don't see why it would, it has it's own locking... Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
