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.
