How to generate mounted image from reproduced C code or repro.prog

[Pengfei Xu]

Hi Dmitry,

Greeting!

How could I generate the mounted image from reproduced C code or repro.prog?
Then it could be convenient for developer to check this issue.

Related community link:
https://lore.kernel.org/linux-xfs/f723cb17-ca68-4db9...@sandeen.net/T/#m94906354a6db930daea7560e0010c83294021425

The reproduced code:
https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/repro.c#L745

I saw reproduced code already mentioned start address: 0x20022ac0, and filled
bytes content, and total size:47378 bytes.

I'm not sure is there some script way to generate the image for mount?
I'm not sure if I fill the bytes like start with "789cecdd" correct for image?

"
memcpy(
(void*)0x20022ac0,
"\x78\x9c\xec\xdd\x7d\x6c\x5d\x75\xfd\xc0\xf1\xd3\xae\x2d\x2d\xfc\x7e\x38"
...
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x70\x53\x00\x00\x00\xff\xff\x87\xfa"
"\x41\x08",
47378);
"
Thanks for your guidance!

Thanks!
BR.

[Aleksandr Nogikh]

Hi,

When syzkaller finds a reproducer, it extracts mounted images
automatically. If it's a local syzkaller instance, the intention was
that it places mount_%d.gz files into the corresponding crash folder
in the workdir. Though I've just found out there was a small bug and
sent a fix [1], you can apply the patch locally if you want to test it
before it's merged.

Otherwise, the big data blob (in your case starting with \x78 and
ending with \x08) is already the gzipped fs image, so all you need is
to save that big binary string to a .gz file (and run gunzip, if you
want the raw image).

[1] https://github.com/google/syzkaller/pull/3921

--
Aleksandr

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/ZG8NGJpfabn%2BJtVt%40xpf.sh.intel.com.

[Pengfei Xu]

Hi Aleksandr,

On 2023-05-25 at 11:00:37 +0200, Aleksandr Nogikh wrote:
> Hi,
>
> When syzkaller finds a reproducer, it extracts mounted images
> automatically. If it's a local syzkaller instance, the intention was
> that it places mount_%d.gz files into the corresponding crash folder
> in the workdir. Though I've just found out there was a small bug and
> sent a fix [1], you can apply the patch locally if you want to test it
> before it's merged.
>

Thanks for your guide!
Yes, I have installed your patch and make syzkaller to have a try, seems it
needs some time to generate the image.
Is there some quickly way to generate the raw image?

> Otherwise, the big data blob (in your case starting with \x78 and
> ending with \x08) is already the gzipped fs image, so all you need is
> to save that big binary string to a .gz file (and run gunzip, if you
> want the raw image).

Thanks for suggestion!
I saved the \x78 and end with \x08 string into one .gz file, there
is still some "\n" newlines in it.
Seems it's not proper .gz file, is there something wrong I did or I missed?

Thanks!
BR.

[Aleksandr Nogikh]

On Thu, May 25, 2023 at 12:00 PM Pengfei Xu <pengf...@intel.com> wrote:
>
> Hi Aleksandr,
>
> On 2023-05-25 at 11:00:37 +0200, Aleksandr Nogikh wrote:
> > Hi,
> >
> > When syzkaller finds a reproducer, it extracts mounted images
> > automatically. If it's a local syzkaller instance, the intention was
> > that it places mount_%d.gz files into the corresponding crash folder
> > in the workdir. Though I've just found out there was a small bug and
> > sent a fix [1], you can apply the patch locally if you want to test it
> > before it's merged.
> >
> Thanks for your guide!
> Yes, I have installed your patch and make syzkaller to have a try, seems it
> needs some time to generate the image.
> Is there some quickly way to generate the raw image?

It needs to hit a bug and. then find a reproducer, this will
unfortunately take some time.

You could speed it up if you paste some syz reproducers for fs bugs to
sys/linux/test, it will then use them as seed programs and crash
faster.

>
> > Otherwise, the big data blob (in your case starting with \x78 and
> > ending with \x08) is already the gzipped fs image, so all you need is
> > to save that big binary string to a .gz file (and run gunzip, if you
> > want the raw image).
> Thanks for suggestion!
> I saved the \x78 and end with \x08 string into one .gz file, there
> is still some "\n" newlines in it.
> Seems it's not proper .gz file, is there something wrong I did or I missed?

Did you try to just paste the binary to a file and then feed it to gunzip?

I mean just something like
memcpy(

"\x78\x9c\xec\xdd\x7d\x6c\x5d\x75\xfd\xc0\xf1\xd3\xae\x2d\x2d\xfc\x7e\x38"
...
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x70\x53\x00\x00\x00\xff\xff\x87\xfa"
"\x41\x08",

1, 47378, fd);

--
Aleksandr

[Xu, Pengfei]

Hi Aleksandr,

> 在 2023年5月25日，18:07，Aleksandr Nogikh <nog...@google.com> 写道：

>
> On Thu, May 25, 2023 at 12:00 PM Pengfei Xu <pengf...@intel.com> wrote:
>>
>> Hi Aleksandr,
>>
>>> On 2023-05-25 at 11:00:37 +0200, Aleksandr Nogikh wrote:
>>> Hi,
>>>
>>> When syzkaller finds a reproducer, it extracts mounted images
>>> automatically. If it's a local syzkaller instance, the intention was
>>> that it places mount_%d.gz files into the corresponding crash folder
>>> in the workdir. Though I've just found out there was a small bug and
>>> sent a fix [1], you can apply the patch locally if you want to test it
>>> before it's merged.
>>>
>> Thanks for your guide!
>> Yes, I have installed your patch and make syzkaller to have a try, seems it
>> needs some time to generate the image.
>> Is there some quickly way to generate the raw image?
>
> It needs to hit a bug and. then find a reproducer, this will
> unfortunately take some time.
>
> You could speed it up if you paste some syz reproducers for fs bugs to
> sys/linux/test, it will then use them as seed programs and crash
> faster.
>

Thnaks for suggesting, I will have a try.

>>
>>> Otherwise, the big data blob (in your case starting with \x78 and
>>> ending with \x08) is already the gzipped fs image, so all you need is
>>> to save that big binary string to a .gz file (and run gunzip, if you
>>> want the raw image).
>> Thanks for suggestion!
>> I saved the \x78 and end with \x08 string into one .gz file, there
>> is still some "\n" newlines in it.
>> Seems it's not proper .gz file, is there something wrong I did or I missed?
>
> Did you try to just paste the binary to a file and then feed it to gunzip?
>
> I mean just something like
> memcpy(
> "\x78\x9c\xec\xdd\x7d\x6c\x5d\x75\xfd\xc0\xf1\xd3\xae\x2d\x2d\xfc\x7e\x38"
> ...
> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x70\x53\x00\x00\x00\xff\xff\x87\xfa"
> "\x41\x08",
> 1, 47378, fd);
>

Ah, I should use memcpy to generate the file, and gunzip it.

Thanks!
BR.

[Aleksandr Nogikh]

Sorry, I meant fwrite, but I think you got the idea :)

--
Aleksandr

[Pengfei Xu]

Hi Aleksandr,

Yes, I'm interested that is there some difference between memcpy and fwrite.
Thanks for your guide!

[Pengfei Xu]

On 2023-05-25 at 14:24:51 +0200, Aleksandr Nogikh wrote:

I used the fwrite and get the file1.gz.
FILE *fp = NULL;
fp = fopen("file1.gz", "w+");
fwrite("\x78\x9c\xec\xdd\x7d\x6c\x5d\x75\xfd\xc0\xf1\xd3\xae\x2d\x2d\xfc\x7e\x38"

...
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x70\x53\x00\x00\x00\xff\xff\x87\xfa"
"\x41\x08",

1,47378,fp);
fclose(fp);

But it could not be gunzip...
# gunzip file1.gz
gzip: file1.gz: not in gzip format

I'm not sure is there something I missed?

And if I used repro binary to reproduce.
It could generate file in syzkaller.UaMQuR/1/file1
I think that's the image, right?

[Aleksandr Nogikh]

Sorry, I have misinformed you :(
I've double checked the source code -- inside syzkaller, we use zlib
because there was a small suitable deflator implementation for
syz-executor. Then we decompress it with zlib and compress it with
gzip to share with users.

So you should use e.g. `pigz -d image.z` to get the raw image.

--
Aleksandr

[Xu, Pengfei]

Hi Aleksandr,

> 在 2023年5月26日，04:41，Aleksandr Nogikh <nog...@google.com> 写道：

Ah, thanks a lot for your guide!

Thanks!
BR.

[Pengfei Xu]

Hi Aleksandr,

Greeting!

Thanks a lot for your help that image for mounting!

And this time I found the similar issue as syzbot found:
Syzbot found the problem: https://syzkaller.appspot.com/bug?extid=a3c8e9ac9f9d77240afd

Bisect result was same as syzbot and my private bisction.

My private syzkaller generated the different reproducer:
https://github.com/xupengfe/syzkaller_logs/blob/main/230611_162818___ext4_ioctl/repro.c

There are 2 files: file0 zlib compressed file and *file1* in reproduced code.

file1 is not zlib file which should started with "78" (maybe 9c next byte).

I'm not sure what type of file1 starts with "7a 14", it doesn't even look
like a compressed file, it can be used directly after fwrite?

Thanks for your reply when you are free. :)

Thanks!
Best regards,

---

[Aleksandr Nogikh]

Hi Pengfei,

On Mon, Jun 12, 2023 at 10:42 AM Pengfei Xu <pengf...@intel.com> wrote:
>
> Hi Aleksandr,
>
> Greeting!
>
> Thanks a lot for your help that image for mounting!
>
> And this time I found the similar issue as syzbot found:
> Syzbot found the problem: https://syzkaller.appspot.com/bug?extid=a3c8e9ac9f9d77240afd
>
> Bisect result was same as syzbot and my private bisction.
>
> My private syzkaller generated the different reproducer:
> https://github.com/xupengfe/syzkaller_logs/blob/main/230611_162818___ext4_ioctl/repro.c
>
> There are 2 files: file0 zlib compressed file and *file1* in reproduced code.
>
> file1 is not zlib file which should started with "78" (maybe 9c next byte).
>
> I'm not sure what type of file1 starts with "7a 14", it doesn't even look
> like a compressed file, it can be used directly after fwrite?

The second blob (starting with "7a 14") is used by
lsetxattr$trusted_overlay_upper, this is not compressed.

We only compress and extract the contents of fs images for syz_mount_image.

--
Aleksandr

[Pengfei Xu]

Hi Aleksandr,

On 2023-06-12 at 11:05:00 +0200, Aleksandr Nogikh wrote:
> Hi Pengfei,
>
> On Mon, Jun 12, 2023 at 10:42 AM Pengfei Xu <pengf...@intel.com> wrote:
> >
> > Hi Aleksandr,
> >
> > Greeting!
> >
> > Thanks a lot for your help that image for mounting!
> >
> > And this time I found the similar issue as syzbot found:
> > Syzbot found the problem: https://syzkaller.appspot.com/bug?extid=a3c8e9ac9f9d77240afd
> >
> > Bisect result was same as syzbot and my private bisction.
> >
> > My private syzkaller generated the different reproducer:
> > https://github.com/xupengfe/syzkaller_logs/blob/main/230611_162818___ext4_ioctl/repro.c
> >
> > There are 2 files: file0 zlib compressed file and *file1* in reproduced code.
> >
> > file1 is not zlib file which should started with "78" (maybe 9c next byte).
> >
> > I'm not sure what type of file1 starts with "7a 14", it doesn't even look
> > like a compressed file, it can be used directly after fwrite?
>
> The second blob (starting with "7a 14") is used by
> lsetxattr$trusted_overlay_upper, this is not compressed.
>
> We only compress and extract the contents of fs images for syz_mount_image.

Ah, thank you for pointing out, it is clear.

Thanks!
Best Regards,
Pengfei