+ 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@collabo...

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