[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+ZQ4Uw7uP36ULiAQ_MSB8KkXhBSZhWTXZaMybn2acK1Sg@mail.gmail.com>
Date: Tue, 7 Apr 2020 12:39:28 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc: syzbot <syzbot+6f1624f937d9d6911e2d@...kaller.appspotmail.com>,
Marco Elver <elver@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get
On Sat, Apr 4, 2020 at 8:14 AM OGAWA Hirofumi
<hirofumi@...l.parknet.co.jp> wrote:
>
> Dmitry Vyukov <dvyukov@...gle.com> writes:
>
> > On Fri, Apr 3, 2020 at 3:36 PM OGAWA Hirofumi
> > <hirofumi@...l.parknet.co.jp> wrote:
> >>
> >> Hm, looks like the race between a directory entry vs a FAT entry. This
> >> bug was happened with the corrupted image? Or the image passes the check
> >> of dosfsck?
> >>
> >> If the corrupted image, it may be hard to prevent the all races. Well,
> >> anyway, the corrupted image of the report will help to detect this
> >> corruption.
> >
> > From the log, it's this program.
> > My bet on a corrupted image. syzkaller does not have format
> > descriptions for fat, so it's just random bytes.
>
> You meant I can regenerate a disk image from that log (if so, how)?
>
> If not, for next time, it would be helpful if syzkaller provides the log
> to regenerate the corrupted image (or saving a corrupted image) to
> reproduce this, then I can try to detect the corruption pattern early.
I've converted the program to C using syz-prog2c:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
then slightly changed the generated program to dump the file to disk
rather than mounting.
The resulting image is attached (archived because it's mostly zeros).
Download attachment "syz_mount_image.tar.gz" of type "application/gzip" (131449 bytes)
Powered by blists - more mailing lists