+ Boris
On 16/12/2021 12:08, Dan Carpenter wrote:
> Hi DRM Devs,
>
> In commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
> from July, Linus added a WARN_ONCE() for "crazy" allocations over 2GB.
> I have a static checker warning for this and most of the warnings are
> from DRM ioctls.
>
> drivers/gpu/drm/lima/lima_drv.c:124 lima_ioctl_gem_submit() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/radeon/radeon_cs.c:291 radeon_cs_parser_init() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/v3d/v3d_gem.c:311 v3d_lookup_bos() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/v3d/v3d_gem.c:319 v3d_lookup_bos() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/v3d/v3d_gem.c:601 v3d_get_multisync_post_deps() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:476 etnaviv_ioctl_gem_submit() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:477 etnaviv_ioctl_gem_submit() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:478 etnaviv_ioctl_gem_submit() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:479 etnaviv_ioctl_gem_submit() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/virtio/virtgpu_ioctl.c:186 virtio_gpu_execbuffer_ioctl() warn: uncapped user size for kvmalloc() will WARN
> drivers/gpu/drm/panfrost/panfrost_drv.c:198 panfrost_copy_in_sync() warn: uncapped user size for kvmalloc() will WARN
I believe this one in Panfrost would be fixed by Boris's series
reworking the submit ioctl[1].
Boris: are you planning on submitting that series soon - or is it worth
cherry picking the rework in patch 5 to fix this issue?
[1]
https://lore.kernel.org/all/20210930190954.1525933-1-boris.brezillon@xxxxxxxxxxxxx/
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:120 amdgpu_cs_parser_init() warn: uncapped user size for kvmalloc() will WARN
>
> These ioctls can all trigger the stack dump. The line numbers are from
> linux next (next-20211214).
>
> I feel like ideally if this could be fixed in a central way, but if not
> then hopefully I've added the relevant lists to the CC.
I've only looked at Panfrost, but at least here we're simply allowing
user space to allocate an arbitrary amount of kernel memory in one go -
which is always going to be a good way of triggering the OOM killer if
nothing else. Boris's series includes a change that means instead trying
to copy an (attacker controller) sized array into the kernel to process,
we copy each each element of the array in turn.
So I don't really see how this could be fixed in a central way (but some
of the other cases might be different).
Thanks,
Steve
> regards,
> dan carpenter
>
