linux-kernel - Re: [PATCH 1/2] ntfs3: fix NULL deref in ntfs_update

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Jun 2022 19:42:07 +0300
From:   Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
To:     Pavel Skripkin <paskripkin@...il.com>, <ntfs3@...ts.linux.dev>
CC:     <syzbot+c95173762127ad76a824@...kaller.appspotmail.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ntfs3: fix NULL deref in ntfs_update_mftmirr



On 6/4/22 14:42, Pavel Skripkin wrote:
> On 4/21/22 23:53, Pavel Skripkin wrote:
>> If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.
>> Code should check this ptr before dereferencing. Syzbot hit this issue
>> via passing wrong mount param as can be seen from log below
>>
>> Fail log:
>> ntfs3: Unknown parameter 'iochvrset'
>> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
>> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
>> CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0
>> ...
>> Call Trace:
>>   <TASK>
>>   put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463
>>   ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363
>>   put_fs_context+0x119/0x7a0 fs/fs_context.c:469
>>   do_new_mount+0x2b4/0xad0 fs/namespace.c:3044
>>   do_mount fs/namespace.c:3383 [inline]
>>   __do_sys_mount fs/namespace.c:3591 [inline]
>>
>> Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
>> Reported-and-tested-by: syzbot+c95173762127ad76a824@...kaller.appspotmail.com
>> Signed-off-by: Pavel Skripkin <paskripkin@...il.com>
> 
> gentle ping
> 
> 
> 
> 
> With regards,
> Pavel Skripkin

1st patch is correct.
2nd patch is a good catch, but I'm not sure if simply ignoring is good.
If mftmirr is broken / missing, then theoretically we can continue working.
But still it's a major fs error.
I'm thinking about exiting mount with error, and if "force" is present,
then continue with mount.
I'll reply again when I'll be sure what is correct behavior.
Thank you for your work!