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: Sun, 10 Mar 2024 09:52:01 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Jan Kara <jack@...e.cz>,
        syzbot <syzbot+28aaddd5a3221d7fd709@...kaller.appspotmail.com>
Cc: axboe@...nel.dk, brauner@...nel.org, jmorris@...ei.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, paul@...l-moore.com,
        serge@...lyn.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [hfs] general protection fault in tomoyo_check_acl (3)

On 2024/01/11 18:21, Jan Kara wrote:
> On Wed 10-01-24 22:44:04, syzbot wrote:
>> syzbot suspects this issue was fixed by commit:
>>
>> commit 6f861765464f43a71462d52026fbddfc858239a5
>> Author: Jan Kara <jack@...e.cz>
>> Date:   Wed Nov 1 17:43:10 2023 +0000
>>
>>     fs: Block writes to mounted block devices
>>
>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15135c0be80000
>> start commit:   a901a3568fd2 Merge tag 'iomap-6.5-merge-1' of git://git.ke..
>> git tree:       upstream
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=7406f415f386e786
>> dashboard link: https://syzkaller.appspot.com/bug?extid=28aaddd5a3221d7fd709
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17b5bb80a80000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10193ee7280000
>>
>> If the result looks correct, please mark the issue as fixed by replying with: 
> 
> Makes some sense since fs cannot be corrupted by anybody while it is
> mounted. I just don't see how the reproducer would be corrupting the
> image... Still probably:
> 
> #syz fix: fs: Block writes to mounted block devices
> 
> and we'll see if syzbot can find new ways to tickle some similar problem.
> 
> 								Honza

Since the reproducer is doing open(O_RDWR) before switching loop devices
using ioctl(LOOP_SET_FD/LOOP_CLR_FD), I think that that commit converted
a run many times, multi threaded program into a run once, single threaded
program. That will likely hide all race bugs.

Does that commit also affect open(3) (i.e. open for ioctl only) case?
If that commit does not affect open(3) case, the reproducer could continue
behaving as run many times, multi threaded program that overwrites
filesystem images using ioctl(LOOP_SET_FD/LOOP_CLR_FD), by replacing
open(O_RDWR) with open(3) ?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ