linux-kernel - Re: [syzbot] [overlayfs?] WARNING in ovl_encode_real

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]

Message-ID: <CAOQ4uxi36iUbYa27c81pNpO7T0vR=rY63b7KACJLP6b4HTJGXQ@mail.gmail.com>
Date: Mon, 4 Nov 2024 20:30:41 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Edward Adam Davis <eadavis@...com>
Cc: syzbot+ec07f6f5ce62b858579f@...kaller.appspotmail.com, 
	linux-kernel@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	miklos@...redi.hu, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [overlayfs?] WARNING in ovl_encode_real_fh

On Wed, Oct 30, 2024 at 11:32 AM Edward Adam Davis <eadavis@...com> wrote:
>
> When the memory is insufficient, the allocation of fh fails, which causes
> the failure to obtain the dentry fid, and finally causes the dentry encoding
> to fail.
> Retry is used to avoid the failure of fh allocation caused by temporary
> insufficient memory.
>
> #syz test
>
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 2ed6ad641a20..1e027a3cf084 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
>         int fh_type, dwords;
>         int buflen = MAX_HANDLE_SZ;
>         uuid_t *uuid = &real->d_sb->s_uuid;
> -       int err;
> +       int err, rtt = 0;
>
>         /* Make sure the real fid stays 32bit aligned */
>         BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
>         BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
>
> +retry:
>         fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
> -       if (!fh)
> +       if (!fh) {
> +               if (!rtt) {
> +                       cond_resched();
> +                       rtt++;
> +                       goto retry;
> +               }
>                 return ERR_PTR(-ENOMEM);
> +       }
>
>         /*
>          * We encode a non-connectable file handle for non-dir, because we
>

This endless loop is out of the question and anyway, syzbot reported
a WARN_ON in line 448:
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure?
What am I missing?

Probably this WARN_ON as well as the one in line 446 should be
relaxed because it is perfectly possible for fs to return negative or
FILEID_INVALID for encoding a file handle even if fs supports encoding
file handles.

Thanks,
Amir.