linux-kernel - Re: linux-next: manual merge of the vfs tree with the overlayfs-fixes tree

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

Date: Wed, 20 Dec 2023 05:21:56 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Al Viro <viro@...iv.linux.org.uk>, Miklos Szeredi <miklos@...redi.hu>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs tree with the overlayfs-fixes tree

On Wed, Dec 20, 2023 at 1:56 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
>   fs/overlayfs/copy_up.c
>
> between commit:
>
>   413ba91089c7 ("ovl: fix dentry reference leak after changes to underlying layers")
>
> from the overlayfs-fixes tree and commit:
>
>   a8b0026847b8 ("rename(): avoid a deadlock in the case of parents having no common ancestor")
>
> from the vfs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

You solved it correctly, but anyway, ovl-fixes is for v6.7-rc7 and I plan
to send a PR for it soon.

I did try to give Al a heads up:
https://lore.kernel.org/linux-unionfs/CAOQ4uxi+4-jyNY6jzNt1wG5xcYSZiSfU0AtCWtF71PSW160zRw@mail.gmail.com/

Thanks,
Amir.

>
> diff --cc fs/overlayfs/copy_up.c
> index 696478f09cc1,e44dc5f66161..000000000000
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@@ -779,13 -757,14 +779,15 @@@ static int ovl_copy_up_workdir(struct o
>          * lock ordering with sb_writers, which shouldn't be held when calling
>          * ovl_copy_up_data(), so lock workdir and destdir and make sure that
>          * temp wasn't moved before copy up completion or cleanup.
>  -       * If temp was moved, abort without the cleanup.
>          */
>         ovl_start_write(c->dentry);
> -       if (lock_rename(c->workdir, c->destdir) != NULL ||
> -           temp->d_parent != c->workdir) {
> +       trap = lock_rename(c->workdir, c->destdir);
> +       if (trap || temp->d_parent != c->workdir) {
>  +              /* temp or workdir moved underneath us? abort without cleanup */
>  +              dput(temp);
>                 err = -EIO;
> +               if (IS_ERR(trap))
> +                       goto out;
>                 goto unlock;
>         } else if (err) {
>                 goto cleanup;