Dear Developers for Linux Memory Management,
We encountered 3 warning crashes when testing the memory management
with Syzkaller and our generated specifications:
1. WARNING: kmalloc bug in gup_test_ioctl
2. WARNING in is_valid_gup_args
3. WARNING in pin_user_pages_fast
The C and syz reproducers and config for the kernel are attached.
For the first one "WARNING: kmalloc bug in gup_test_ioctl", it seems
that the check `if (gup->size > ULONG_MAX)`
(https://elixir.bootlin.com/linux/v6.7-rc8/source/mm/gup_test.c#L111)
is not accurate, which should be INT_MAX * PAGE_SIZE / sizeof(void *),
based o `pages = kvcalloc(nr_pages, sizeof(void *), GFP_KERNEL);`
(https://elixir.bootlin.com/linux/v6.7-rc8/source/mm/gup_test.c#L115).
For the second one "WARNING in is_valid_gup_args" and "WARNING in
pin_user_pages_fast“, the root causes are kind of similar. They both
fail to check the `gup_flags` in `is_valid_gup_args`
(https://elixir.bootlin.com/linux/v6.7-rc8/source/mm/gup.c#L2245) and
`internal_get_user_pages_fast`
(https://elixir.bootlin.com/linux/v6.7-rc8/source/mm/gup.c#L3185)
respectively. `gup_flags` is provided by user, thus, it could be
arbitrary value. I think it would be better not to use `WARN_ON_ONCE`
to check the validity of this flag.
If you have any questions or require more information, please feel
free to contact us.
Reported-by: Chenyuan Yang <[email protected]>
Best,
Chenyuan
On Fri, Jan 26, 2024 at 11:04:53AM -0600, Chenyuan Yang wrote:
> Dear Developers for Linux Memory Management,
>
> We encountered 3 warning crashes when testing the memory management
> with Syzkaller and our generated specifications:
These all come in through gup_test_ioctl(). It's my impression
that this is something you can enable to wreak havoc on your kernel
and it's not something which should ever be exposed to fuzzers.
Hello Matthew,
Thanks very much for your prompt response!
For `gup_test_ioctl`, we generate the descriptions for it for
interaction and testing:
```
openat$gup_test(fd const[AT_FDCWD], file ptr[in,
string["/sys/kernel/debug/gup_test"]], flags const[O_RDWR], mode
const[0]) fd_gup_test
ioctl$PIN_FAST_BENCHMARK(fd fd_gup_test, cmd
const[PIN_FAST_BENCHMARK], arg ptr[inout, gup_test])
..
gup_test {
...
gup_flags int32
...
}
```
In this context, I would like to seek your valued opinion. Do you
believe it would be more prudent to avoid fuzz testing the
`gup_test_ioctl`, or are the warnings in `gup_test_ioctl` an
anticipated outcome?
It seems that `gup_test_ioctl` can indeed be exposed in the kernel by
accessing /sys/kernel/debug/gup_test.
Thank you once again for your time and expertise.
Best,
Chenyuan
On Fri, Jan 26, 2024 at 11:11 AM Matthew Wilcox <[email protected]> wrote:
>
> On Fri, Jan 26, 2024 at 11:04:53AM -0600, Chenyuan Yang wrote:
> > Dear Developers for Linux Memory Management,
> >
> > We encountered 3 warning crashes when testing the memory management
> > with Syzkaller and our generated specifications:
>
> These all come in through gup_test_ioctl(). It's my impression
> that this is something you can enable to wreak havoc on your kernel
> and it's not something which should ever be exposed to fuzzers.
>
>
>
>
>
On Fri, Jan 26, 2024 at 11:31:26AM -0600, Chenyuan Yang wrote:
> In this context, I would like to seek your valued opinion. Do you
> believe it would be more prudent to avoid fuzz testing the
> `gup_test_ioctl`, or are the warnings in `gup_test_ioctl` an
> anticipated outcome?
It seems like a waste of time. Debian certainly disables it, so
unless you can find a distro who enables it, I wouldn't bother.
> It seems that `gup_test_ioctl` can indeed be exposed in the kernel by
> accessing /sys/kernel/debug/gup_test.
If someone wants to fix these things, they can, but it just doesn't
seem worth doing. Part of the art of fuzz testing is finding things
that are worth testing.
On 1/26/24 10:34, Matthew Wilcox wrote:
> On Fri, Jan 26, 2024 at 11:31:26AM -0600, Chenyuan Yang wrote:
>> In this context, I would like to seek your valued opinion. Do you
>> believe it would be more prudent to avoid fuzz testing the
>> `gup_test_ioctl`, or are the warnings in `gup_test_ioctl` an
>> anticipated outcome?
>
> It seems like a waste of time. Debian certainly disables it, so
> unless you can find a distro who enables it, I wouldn't bother.
+1000! The purpose of gup_test_ioctl is to provide a way to invoke,
from user space, direct testing of some kernel interfaces that are
not actually exposed to user space for production systems.
Fuzzing this interface is exactly what you should never do. :)
>
>> It seems that `gup_test_ioctl` can indeed be exposed in the kernel by
>> accessing /sys/kernel/debug/gup_test.
That's a debug interface.
>
> If someone wants to fix these things, they can, but it just doesn't
> seem worth doing. Part of the art of fuzz testing is finding things
> that are worth testing.
I'll go just slightly further, even: some conceivable "fixes" could end
up hurting test coverage. Without providing any real benefit.
thanks,
--
John Hubbard
NVIDIA
Hello John and Matthew,
Thanks a lot for your further explanation of this issue! It really
helps me have a deeper understanding of the testing interface used in
the kernel.
Best,
Chenyuan
On Fri, Jan 26, 2024 at 1:09 PM John Hubbard <[email protected]> wrote:
>
> On 1/26/24 10:34, Matthew Wilcox wrote:
> > On Fri, Jan 26, 2024 at 11:31:26AM -0600, Chenyuan Yang wrote:
> >> In this context, I would like to seek your valued opinion. Do you
> >> believe it would be more prudent to avoid fuzz testing the
> >> `gup_test_ioctl`, or are the warnings in `gup_test_ioctl` an
> >> anticipated outcome?
> >
> > It seems like a waste of time. Debian certainly disables it, so
> > unless you can find a distro who enables it, I wouldn't bother.
>
> +1000! The purpose of gup_test_ioctl is to provide a way to invoke,
> from user space, direct testing of some kernel interfaces that are
> not actually exposed to user space for production systems.
>
> Fuzzing this interface is exactly what you should never do. :)
>
> >
> >> It seems that `gup_test_ioctl` can indeed be exposed in the kernel by
> >> accessing /sys/kernel/debug/gup_test.
>
> That's a debug interface.
>
> >
> > If someone wants to fix these things, they can, but it just doesn't
> > seem worth doing. Part of the art of fuzz testing is finding things
> > that are worth testing.
>
> I'll go just slightly further, even: some conceivable "fixes" could end
> up hurting test coverage. Without providing any real benefit.
>
>
> thanks,
> --
> John Hubbard
> NVIDIA
>
>