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: <bcd184f1-acbc-46c7-9e30-045a8f17fc5c@I-love.SAKURA.ne.jp>
Date: Tue, 16 Sep 2025 12:48:23 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: almaz.alexandrovich@...agon-software.com, ntfs3@...ts.linux.dev
Cc: syzbot <syzbot+bdeb22a4b9a09ab9aa45@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ntfs3?] INFO: trying to register non-static key in
 ntfs_set_size

Well, we need to also initialize ni->file.run_lock, for vfs_truncate() now
passes the

	/* For directories it's -EISDIR, for other non-regulars - -EINVAL */
	if (S_ISDIR(inode->i_mode))
		return -EISDIR;
	if (!S_ISREG(inode->i_mode))
		return -EINVAL;

check. But do we really want to pretend as if S_IFREG ?

diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
index 37cbbee7fa58..ea2193ebf8fc 100644
--- a/fs/ntfs3/inode.c
+++ b/fs/ntfs3/inode.c
@@ -471,6 +471,8 @@ static struct inode *ntfs_read_mft(struct inode *inode,
                   fname->home.seq == cpu_to_le16(MFT_REC_EXTEND)) {
                /* Records in $Extend are not a files or general directories. */
                inode->i_op = &ntfs_file_inode_operations;
+               mode = S_IFREG;
+               init_rwsem(&ni->file.run_lock);
        } else {
                err = -EINVAL;
                goto out;

Are records in $Extend expected to be truncated to arbitrary size? Should we
prepend something other than S_IFREG (at least S_IFREG so that truncate()
will fail, or possibly S_IFSOCK so that open() will fail) ?

On 2025/09/16 3:17, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    590b221ed425 Add linux-next specific files for 20250912
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1379b934580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=12a1d1f3a8199632
> dashboard link: https://syzkaller.appspot.com/bug?extid=bdeb22a4b9a09ab9aa45
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=144aa762580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=117c8762580000

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ