Excerpts from Alex Xu (Hello71)'s message of February 15, 2021 9:53 am:

This issue was discussed at [0] and following, and the solution was to
clamp the size at KMALLOC_MAX_LEN. However, KMALLOC_MAX_LEN is a maximum
allocation, and may be difficult to allocate in low memory conditions.

Since maxlen is already exposed, we can allocate approximately the right
amount directly, fixing up those drivers which set a bogus maxlen. These
drivers were located based on those which had copy_x_user replaced in
32927393dc1c, on the basis that other drivers either use builtin proc_*
handlers, or do not access the data pointer. The latter is OK because
maxlen only needs to be an upper limit.

[0] https://lore.kernel.org/lkml/1fc7ce08-26a7-59ff-e580-4e6c22554752@oracle.com/ (local)

Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Signed-off-by: Alex Xu (Hello71) <redacted>

Yeah, no, this doesn't work. A bunch of functions call proc_* but don't 
set maxlen, and it's annoying to check this statically. Also causes 
weird failures elsewhere. May need to think of a better solution here 
(kvzalloc?).