Re: [PATCH (urgent)] vfs: fix uninitialized uid/gid in chown_common()

[Seth Forshee <sforshee@kernel.org>]

On Mon, Sep 19, 2022 at 07:25:39PM -0500, Seth Forshee wrote:
> On Mon, Sep 19, 2022 at 06:41:02PM -0500, Serge E. Hallyn wrote:
> > On Mon, Sep 19, 2022 at 05:14:14PM +0200, Christian Brauner wrote:
> > > On Mon, Sep 19, 2022 at 05:12:25PM +0200, Christian Brauner wrote:
> > > > On Mon, Sep 19, 2022 at 08:05:12PM +0900, Tetsuo Handa wrote:
> > > > > syzbot is reporting uninit-value in tomoyo_path_chown() [1], for
> > > > > chown_common() is by error passing uninitialized newattrs.ia_vfsuid to
> > > > > security_path_chown() via from_vfsuid() when user == -1 is passed.
> > > > > We must initialize newattrs.ia_vfs{u,g}id fields in order to make
> > > > > from_vfs{u,g}id() work.
> > > > > 
> > > > > Link: https://syzkaller.appspot.com/bug?extid=541e21dcc32c4046cba9 [1]
> > > > > Reported-by: syzbot <syzbot+541e21dcc32c4046cba9@syzkaller.appspotmail.com>
> > > > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > > > ---
> > > > 
> > > > Odd that we didn't get any of the reports. Thanks for relying this.
> > > > I'll massage this a tiny bit, apply and will test with syzbot.
> > > 
> > > Fyi, Seth.
> > 
> > Because the modules are ignoring ia_valid & ATTR_XID?
> 
> security_path_chown() takes ids as arguments, not struct iattr.
> 
>   int security_path_chown(const struct path *path, kuid_t uid, kgid_t gid)
> 
> The ones being passed are now taken from iattr and thus potentially not
> initialized. Even if we change it to only call security_path_chown()
> when one of ATTR_{U,G}ID is set the other might not be set, so
> initializing iattr.ia_vfs{u,g}id makes sense to me and should match the
> old behavior of passing invalid ids in this situation.
> 
> What I don't understand is why security_path_chown() is even necessary
> when we also have security_inode_setattr(), which also gets called
> during chown and gets the full iattr struct. Maybe there's a good
> reason, but at first glance it seems like it could do any checks that
> security_path_chown() is doing.

Maybe the important difference is that one takes the path as an argument
and the other only takes the dentry? I guess that might be it, though it
still feels kind of redundant.