On Fri, May 18, 2018 at 5:40 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, May 18, 2018 at 05:11:20PM +0200, Miklos Szeredi 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. > > IMO you are using the wrong model; just create the underlying object, > then do what lookup would for overlayfs inode creation, then > d_splice_alias() + dput() of return value (if non-IS_ERR). That's fine. Issue is with inode allocation. I'd really like to avoid dealing with failure after a successful create. Doing the iget5_locked() can fail with -ENOMEM, altough it's arguably a rare occurrence. 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
