[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112072406.GF22493@dhcp22.suse.cz>
Date: Tue, 12 Jan 2021 08:24:06 +0100
From: Michal Hocko <mhocko@...e.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Xiaoming Ni <nixiaoming@...wei.com>, linux-kernel@...r.kernel.org,
mcgrof@...nel.org, keescook@...omium.org, yzaikin@...gle.com,
adobriyan@...il.com, linux-fsdevel@...r.kernel.org, vbabka@...e.cz,
andy.shevchenko@...il.com, wangle6@...wei.com
Subject: Re: [PATCH v3] proc_sysctl: fix oops caused by incorrect command
parameters.
On Mon 11-01-21 22:28:45, Andrew Morton wrote:
> On Tue, 12 Jan 2021 14:24:05 +0800 Xiaoming Ni <nixiaoming@...wei.com> wrote:
>
> > On 2021/1/12 12:33, Andrew Morton wrote:
> > > On Tue, 12 Jan 2021 11:31:55 +0800 Xiaoming Ni <nixiaoming@...wei.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
Powered by blists - more mailing lists