Excerpts from Christoph Hellwig's message of February 16, 2021 3:47 am:

How do these maxlen = 0 entries even survive the sysctl_check_table
check?

maxlen!=0 is only checked for "default" handlers, e.g. proc_dostring, 
proc_dointvec. it is not checked for non-default handlers, because some 
of them use fixed lengths.

my patch is not correct though because some drivers neither set proper 
maxlen nor use memcpy themselves; instead, they construct a ctl_table on 
the stack and call proc_*.

Please split this into one patch each each subsystem that sets maxlen
to 0 and the actual change to proc_sysctl.c.

I will do this with a new patch version once I figure out a way to 
comprehensively fix all the drivers setting bogus values for maxlen 
(sometimes maxlen=0 is valid if only blank writes are permitted, and 
some drivers set random values which have no relation to the actual read 
size).

Thank you for the review.