Re: [PATCH v3] proc_sysctl: fix oops caused by incorrect command parameters.

[Michal Hocko <mhocko@suse.com>]

On Mon 11-01-21 22:28:45, Andrew Morton wrote:
> On Tue, 12 Jan 2021 14:24:05 +0800 Xiaoming Ni <nixiaoming@huawei.com> wrote:
> 
> > On 2021/1/12 12:33, Andrew Morton wrote:
> > > On Tue, 12 Jan 2021 11:31:55 +0800 Xiaoming Ni <nixiaoming@huawei.com> wrote:
> > > 
> > >> The process_sysctl_arg() does not check whether val is empty before
> > >>   invoking strlen(val). If the command line parameter () is incorrectly
> > >>   configured and val is empty, oops is triggered.
> > >>
> > >> --- a/fs/proc/proc_sysctl.c
> > >> +++ b/fs/proc/proc_sysctl.c
> > >> @@ -1770,6 +1770,9 @@ static int process_sysctl_arg(char *param, char *val,
> > >>   			return 0;
> > >>   	}
> > >>   
> > >> +	if (!val)
> > >> +		return -EINVAL;
> > >> +
> > > 
> > > I think v2 (return 0) was preferable.  Because all the other error-out
> > > cases in process_sysctl_arg() also do a `return 0'.
> > 
> > https://lore.kernel.org/lkml/bc098af4-c0cd-212e-d09d-46d617d0acab@huawei.com/
> > 
> > patch4:
> >      +++ b/fs/proc/proc_sysctl.c
> >      @@ -1757,6 +1757,9 @@ static int process_sysctl_arg(char *param, 
> > char *val,
> >              loff_t pos = 0;
> >              ssize_t wret;
> > 
> >      +       if (!val)
> >      +               return 0;
> >      +
> >              if (strncmp(param, "sysctl", sizeof("sysctl") - 1) == 0) {
> >                      param += sizeof("sysctl") - 1;
> > 
> > Is this the version you're talking about?
> 
> yes, but as a separate patch.  The bugfix comes first.
> 
> > > 
> > > If we're going to do a separate "patch: make process_sysctl_arg()
> > > return an errno instead of 0" then fine, we can discuss that.  But it's
> > > conceptually a different work from fixing this situation.
> > > .
> > > 
> > However, are the logs generated by process_sysctl_arg() clearer and more 
> > accurate than parse_args()? Should the logs generated by 
> > process_sysctl_arg() be deleted?
> 
> I think the individual logs are very useful and should be retained.

Yes, other sysfs specific error messages are likely useful. I just fail
to see why a missing value should be handled here when there is an
existing handling in the caller. Not sure whether a complete shadow
reporting in process_sysctl_arg is a deliberate decision or not.
Vlastimil?

Anyway one way or the other, all I care about is to have a reporting in
place because this shouldn't be a silent failure.

-- 
Michal Hocko
SUSE Labs