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@xxxxxxxxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> > > > ---
> > >
> > > 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.
Seth
