[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1614436629.aqa2hys64t.none@localhost>
Date: Sat, 27 Feb 2021 09:41:36 -0500
From: "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
To: Christoph Hellwig <hch@....de>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
Kees Cook <keescook@...omium.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Luis Chamberlain <mcgrof@...nel.org>,
Andrey Ignatov <rdna@...com>,
Al Viro <viro@...iv.linux.org.uk>,
Iurii Zaikin <yzaikin@...gle.com>
Subject: Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen
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.
Powered by blists - more mailing lists