Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4a3a6527-4a19-699a-d7a5-21249254522b@I-love.SAKURA.ne.jp>
Date:   Mon, 17 Oct 2022 23:29:01 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: [syzbot] general protection fault in security_inode_getattr
Content-Language: en-US
To:     Paul Moore <paul@paul-moore.com>, miklos@szeredi.hu,
        linux-unionfs@vger.kernel.org
Cc:     dvyukov@google.com, hdanton@sina.com,
        linux-fsdevel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com>,
        yhs@fb.com, omosnace@redhat.com
References: <0000000000008caae305ab9a5318@google.com>
 <000000000000618a8205eb160404@google.com>
 <CAHC9VhRt2vpArZ=bOrkBOGiAuoTdEcp2PRP5NtbyEZkuMHvopA@mail.gmail.com>
From:   Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
In-Reply-To: <CAHC9VhRt2vpArZ=bOrkBOGiAuoTdEcp2PRP5NtbyEZkuMHvopA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/10/16 23:52, Paul Moore wrote:
> It doesn't look like this is a problem with
> security_inode_getattr()/d_backing_inode() as it appears that the
> passed path struct pointer has a bogus/NULL path->dentry pointer and
> to the best of my knowledge it would appear that vfs_getattr() (the
> caller) requires a valid path->dentry value.
> 
> Looking quickly at the code, I wonder if there is something wonky
> going on in the overlayfs code, specifically ovl_copy_up_flags() and
> ovl_copy_up_one() as they have to play a number of tricks to handle
> the transparent overlays and copy up operations.  I'm not an overlayfs
> expert, but that seems like a good place to start digging further into
> this.

Right. This is a bug in overlayfs code. Probably due to some race condition,
ovl_copy_up_flags() is calling ovl_copy_up_one() with "next" dentry with
"struct ovl_entry"->numlower == 0. As a result, ovl_path_lower() from
ovl_copy_up_one() fills ctx.lowerpath with NULLs, and vfs_getattr() gets
surprised by ctx.lowerpath.dentry == NULL.

If we can't avoid selecting a dentry with "struct ovl_entry"->numlower == 0 using
some lock, I guess that we would need to use a workaround suggested by Hillf Danton
at https://groups.google.com/g/syzkaller-bugs/c/xDcxFKSppfE/m/b38Tv7LoAAAJ .