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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ