A bug was found in Linux Kernel 6.6+: KASAN: slab-use-after-free in iommufd_test (with POC)

A bug was found in Linux Kernel 6.6+: KASAN: slab-use-after-free in iommufd_test (with POC)

[Zhang Zhiyu]

Hi upstream community,

I am fuzzing a LTS version of Linux kernel 6.6 with my modified
syzkaller and I find a bug named "KASAN: slab-use-after-free in
iommufd_test". By analyzing the call trace in bug report, I address
the root cause of this bug at drivers/iommu/iommufd. An iommufd_object
is allocated in one task through
iommufd_fops_ioctl->iommufd_ioas_alloc_ioctl->iommufd_ioas_alloc and
freed in another task through iommufd_fops_ioctl->iommufd_destroy.
Then when the kernel invokes the calls
iommufd_fops_ioctl->iommufd_test->iommufd_test_add_reserved->iommufd_put_object,
an use-after-free read will occur. Detailed report, log, repro, config
can be found in this google drive link:
https://drive.usercontent.google.com/download?id=1nDJWUstYJNcC1zJ6q1rhB5zB0uV2yGvg&export=download&authuser=0&confirm=t

The steps to reproduce the bug:
1. compile the kernel 6.6 with provided Linux-6.6.config
2. boot a qemu vm that runs the compiled kernel
3. scp the repro.c (repro.prog is not recommended) to the vm and
compile it with gcc -pthread repro.c -o repro
4. execute ./repro and you will see the output stucks for a while and
then KASAN is triggered and kernel panic.
5. you can speed up the crash by setting up another ssh shell to
execute ./repro again.

I have reproduced it on 6.6 and 6.6.1 (but haven't verified on the
latest ver 6.6.8 yet). I didn't find any related reports on the
internet, which indicates that it may be a 0day. Hope the upstream can
help check and fix it. And I'll be happy to assist if needed.

Best,
Zhiyu Zhang

RE: A bug was found in Linux Kernel 6.6+: KASAN: slab-use-after-free in iommufd_test (with POC)

[Tian, Kevin]

> From: Zhang Zhiyu <zhiyuzhang999@gmail.com>
> Sent: Wednesday, December 27, 2023 5:03 PM
> 
> Hi upstream community,
> 
> I am fuzzing a LTS version of Linux kernel 6.6 with my modified
> syzkaller and I find a bug named "KASAN: slab-use-after-free in
> iommufd_test". By analyzing the call trace in bug report, I address
> the root cause of this bug at drivers/iommu/iommufd. An iommufd_object
> is allocated in one task through
> iommufd_fops_ioctl->iommufd_ioas_alloc_ioctl->iommufd_ioas_alloc and
> freed in another task through iommufd_fops_ioctl->iommufd_destroy.
> Then when the kernel invokes the calls
> iommufd_fops_ioctl->iommufd_test->iommufd_test_add_reserved-
> >iommufd_put_object,
> an use-after-free read will occur. Detailed report, log, repro, config
> can be found in this google drive link:
> https://drive.usercontent.google.com/download?id=1nDJWUstYJNcC1zJ6q1r
> hB5zB0uV2yGvg&export=download&authuser=0&confirm=t
> 
> The steps to reproduce the bug:
> 1. compile the kernel 6.6 with provided Linux-6.6.config
> 2. boot a qemu vm that runs the compiled kernel
> 3. scp the repro.c (repro.prog is not recommended) to the vm and
> compile it with gcc -pthread repro.c -o repro
> 4. execute ./repro and you will see the output stucks for a while and
> then KASAN is triggered and kernel panic.
> 5. you can speed up the crash by setting up another ssh shell to
> execute ./repro again.
> 
> I have reproduced it on 6.6 and 6.6.1 (but haven't verified on the
> latest ver 6.6.8 yet). I didn't find any related reports on the
> internet, which indicates that it may be a 0day. Hope the upstream can
> help check and fix it. And I'll be happy to assist if needed.
> 

Could you try below fix? or just use latest kernel which already includes it:

https://lore.kernel.org/all/2-v2-ca9e00171c5b+123-iommufd_syz4_jgg@nvidia.com/

Re: A bug was found in Linux Kernel 6.6+: KASAN: slab-use-after-free in iommufd_test (with POC)

[Zhang Zhiyu]

Hi Kevin,

Thanks for your advice.

I check the patch which has been applied in Linux-6.7-rc5+, while not
in the latest stable Linux-6.6.8. As a result, my poc is still
reproducible on 6.6.8, but not on 6.7-rc5+. Maybe the stable line of
Linux kernel should apply the patch asap.

Seems that I am late to this bug. Although the call trace of my poc is
slightly different from the disclosed "KASAN: slab-use-after-free Read
in iommufd_vfio_ioas"
(https://syzkaller.appspot.com/bug?extid=d31adfb277377ef8fcba), they
share the same root cause.

Best,
Zhiyu

Tian, Kevin <kevin.tian@intel.com> 于2023年12月28日周四 15:28写道：
>
> > From: Zhang Zhiyu <zhiyuzhang999@gmail.com>
> > Sent: Wednesday, December 27, 2023 5:03 PM
> >
> > Hi upstream community,
> >
> > I am fuzzing a LTS version of Linux kernel 6.6 with my modified
> > syzkaller and I find a bug named "KASAN: slab-use-after-free in
> > iommufd_test". By analyzing the call trace in bug report, I address
> > the root cause of this bug at drivers/iommu/iommufd. An iommufd_object
> > is allocated in one task through
> > iommufd_fops_ioctl->iommufd_ioas_alloc_ioctl->iommufd_ioas_alloc and
> > freed in another task through iommufd_fops_ioctl->iommufd_destroy.
> > Then when the kernel invokes the calls
> > iommufd_fops_ioctl->iommufd_test->iommufd_test_add_reserved-
> > >iommufd_put_object,
> > an use-after-free read will occur. Detailed report, log, repro, config
> > can be found in this google drive link:
> > https://drive.usercontent.google.com/download?id=1nDJWUstYJNcC1zJ6q1r
> > hB5zB0uV2yGvg&export=download&authuser=0&confirm=t
> >
> > The steps to reproduce the bug:
> > 1. compile the kernel 6.6 with provided Linux-6.6.config
> > 2. boot a qemu vm that runs the compiled kernel
> > 3. scp the repro.c (repro.prog is not recommended) to the vm and
> > compile it with gcc -pthread repro.c -o repro
> > 4. execute ./repro and you will see the output stucks for a while and
> > then KASAN is triggered and kernel panic.
> > 5. you can speed up the crash by setting up another ssh shell to
> > execute ./repro again.
> >
> > I have reproduced it on 6.6 and 6.6.1 (but haven't verified on the
> > latest ver 6.6.8 yet). I didn't find any related reports on the
> > internet, which indicates that it may be a 0day. Hope the upstream can
> > help check and fix it. And I'll be happy to assist if needed.
> >
>
> Could you try below fix? or just use latest kernel which already includes it:
>
> https://lore.kernel.org/all/2-v2-ca9e00171c5b+123-iommufd_syz4_jgg@nvidia.com/