[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251204082156.GK1712166@ZenIV>
Date: Thu, 4 Dec 2025 08:21:56 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: syzbot <syzbot+d222f4b7129379c3d5bc@...kaller.appspotmail.com>,
brauner@...nel.org, jack@...e.cz, jlbec@...lplan.org,
joseph.qi@...ux.alibaba.com, linkinjeon@...nel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
mark@...heh.com, ocfs2-devel@...ts.linux.dev,
sj1557.seo@...sung.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [exfat?] [ocfs2?] kernel BUG in link_path_walk
On Thu, Dec 04, 2025 at 08:45:08AM +0100, Mateusz Guzik wrote:
> Or to put it differently, lookup got entered with a bogus state of a
> dentry claiming it is a directory, with an inode which is not. Per the
> i_mode reported in the opening mail it is a regular file instead.
>
> While I don't see how this can happen,
->i_op set to something with ->lookup != NULL, ->i_mode - to regular.
Which is to say, bogus ->i_mode change somewhere.
Theoretically it should bail out, having detected the type change
(on inode_wrong_type()). I'd suggest slapping
BUG_ON(inode_wrong_type(inode, new_i_mode_value));
in front of all reassignments (ocfs2_populate_inode() is the initialization
and thus exempt; all other stores to ->i_mode of struct inode in there
are, in principle, suspect. Something like inode->i_mode &= ~S_ISUID
doesn't need checking - we obviously can't change the type there.
Unpleasant part is that struct ocfs2_dinode also has a member called
i_mode (__le16, that one), so stores to that clutter the grep results...
Powered by blists - more mailing lists