On September 11, 2023 6:55:32 PM PDT, Dave Airlie <airlied@xxxxxxxxx> wrote: >On Tue, 12 Sept 2023 at 11:27, Kees Cook <kees@xxxxxxxxxx> wrote: >> >> On September 8, 2023 12:59:39 PM PDT, Philipp Stanner <pstanner@xxxxxxxxxx> wrote: >> >Hi! >> > >> >David Airlie suggested that we could implement new wrappers around >> >(v)memdup_user() for duplicating user arrays. >> > >> >This small patch series first implements the two new wrapper functions >> >memdup_array_user() and vmemdup_array_user(). They calculate the >> >array-sizes safely, i.e., they return an error in case of an overflow. >> > >> >It then implements the new wrappers in two components in kernel/ and two >> >in the drm-subsystem. >> > >> >In total, there are 18 files in the kernel that use (v)memdup_user() to >> >duplicate arrays. My plan is to provide patches for the other 14 >> >successively once this series has been merged. >> > >> > >> >Changes since v1: >> >- Insert new headers alphabetically ordered >> >- Remove empty lines in functions' docstrings >> >- Return -EOVERFLOW instead of -EINVAL from wrapper functions >> > >> > >> >@Andy: >> >I test-build it for UM on my x86_64. Builds successfully. >> >A kernel build (localmodconfig) for my Fedora38 @ x86_64 does also boot >> >fine. >> > >> >If there is more I can do to verify the early boot stages are fine, >> >please let me know! >> > >> >P. >> > >> >Philipp Stanner (5): >> > string.h: add array-wrappers for (v)memdup_user() >> > kernel: kexec: copy user-array safely >> > kernel: watch_queue: copy user-array safely >> > drm_lease.c: copy user-array safely >> > drm: vmgfx_surface.c: copy user-array safely >> > >> > drivers/gpu/drm/drm_lease.c | 4 +-- >> > drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 +-- >> > include/linux/string.h | 40 +++++++++++++++++++++++++ >> > kernel/kexec.c | 2 +- >> > kernel/watch_queue.c | 2 +- >> > 5 files changed, 46 insertions(+), 6 deletions(-) >> > >> >> Nice. For the series: >> >> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > >Hey Kees, > >what tree do you think it would best to land this through? I'm happy >to send the initial set from a drm branch, but also happy to have it >land via someone with a better process. Feel free to take it via drm. Usually string.h doesn't get a lot of changes (and even then it's normally additive) so conflicts are rare/easy. :) -Kees -- Kees Cook _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
