MIME-Version: 1.0
References: <20211206071859.324729-1-bernard@vivo.com> <PSAPR06MB4021DF6A6135859C2332E5B9DF6E9@PSAPR06MB4021.apcprd06.prod.outlook.com>
In-Reply-To: <PSAPR06MB4021DF6A6135859C2332E5B9DF6E9@PSAPR06MB4021.apcprd06.prod.outlook.com>
From:   Ondrej Mosnacek <omosnace@redhat.com>
Date:   Thu, 9 Dec 2021 10:59:41 +0100
Message-ID: <CAFqZXNsSDFKDJ8PX2bu9p4-pHH+3yAEoy=XZ+uHB=XqM=k5yhQ@mail.gmail.com>
Subject: Re: [PATCH v2] security/selinux: fix potential memleak in error branch
To:     =?UTF-8?B?6LW15Yab5aWO?= <bernard@vivo.com>
Cc:     Paul Moore <paul@paul-moore.com>,
        Stephen Smalley <stephen.smalley.work@gmail.com>,
        Eric Paris <eparis@parisplace.org>,
        SElinux list <selinux@vger.kernel.org>,
        Linux kernel mailing list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Dec 7, 2021 at 1:05 PM =E8=B5=B5=E5=86=9B=E5=A5=8E <bernard@vivo.co=
m> wrote:
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: bernard@vivo.com <bernard@vivo.com> =E4=BB=
=A3=E8=A1=A8 Ondrej Mosnacek
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B412=E6=9C=886=E6=97=A5 =
17:11
> =E6=94=B6=E4=BB=B6=E4=BA=BA: =E8=B5=B5=E5=86=9B=E5=A5=8E <bernard@vivo.co=
m>
> =E6=8A=84=E9=80=81: Paul Moore <paul@paul-moore.com>; Stephen Smalley <st=
ephen.smalley.work@gmail.com>; Eric Paris <eparis@parisplace.org>; SElinux =
list <selinux@vger.kernel.org>; Linux kernel mailing list <linux-kernel@vge=
r.kernel.org>
> =E4=B8=BB=E9=A2=98: Re: [PATCH v2] security/selinux: fix potential memlea=
k in error branch
>
> On Mon, Dec 6, 2021 at 8:19 AM Bernard Zhao <bernard@vivo.com> wrote:
> > This patch try to fix potential memleak in error branch.
> >
> > Signed-off-by: Bernard Zhao <bernard@vivo.com>
> > ---
> >  security/selinux/hooks.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index
> > 62d30c0a30c2..8dc140399a23 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -983,18 +983,22 @@ static int selinux_sb_clone_mnt_opts(const
> > struct super_block *oldsb,  static int selinux_add_opt(int token,
> > const char *s, void **mnt_opts)  {
> >         struct selinux_mnt_opts *opts =3D *mnt_opts;
> > +       bool is_alloc_opts =3D false;
> >
> >         if (token =3D=3D Opt_seclabel)      /* eaten and completely ign=
ored */
> >                 return 0;
> >
> > +       if (!s)
> > +               return -ENOMEM;
> > +
> >         if (!opts) {
> >                 opts =3D kzalloc(sizeof(struct selinux_mnt_opts), GFP_K=
ERNEL);
> >                 if (!opts)
> >                         return -ENOMEM;
> >                 *mnt_opts =3D opts;
> > +               is_alloc_opts =3D true;
> >         }
> > -       if (!s)
> > -               return -ENOMEM;
> > +
> >         switch (token) {
> >         case Opt_context:
> >                 if (opts->context || opts->defcontext) @@ -1019,6
> > +1023,8 @@ static int selinux_add_opt(int token, const char *s, void **=
mnt_opts)
> >         }
> >         return 0;
> >  Einval:
> > +       if (is_alloc_opts)
> > +               kfree(opts);
> >         pr_warn(SEL_MOUNT_FAIL_MSG);
> >         return -EINVAL;
> >  }
> > --
> > 2.33.1
>
> >The problem is a bit more tricky... As is, this patch will lead to doubl=
e frees in some cases. Look at security_sb_eat_lsm_opts() callers, for exam=
ple - some of them don't do anything when error is returned, some call
> >security_free_mnt_opts() on the opts regardless, some will let it store =
the opts in fc->security, where
> >put_fs_context() will eventually call security_free_mnt_opts() on them.
>
> >You need to at least *mnt_opts =3D NULL after kfree(opts), but it would =
be also nice to make the LSM hook callers more consistent in what they do i=
n the error path and document the fact that *mnt_opts will be NULL
> >on error in lsm_hooks.h (in case of the sb_eat_lsm_opts hook).
> Hi Ondrej Mosnacek:
>
> Thanks for your comments!
> I am not sure if there is some gap, for this part " it would be also nice=
 to make the LSM hook callers more consistent in what they do in the error =
path and document the fact that *mnt_opts will be NULL
> on error in lsm_hooks.h (in case of the sb_eat_lsm_opts hook)"
> I am not sure if this is OK:
> 116   * @sb_eat_lsm_opts:
> 117   *         Eat (scan @orig options) and save them in @mnt_opts.
> 118   *     If error is returned, then the *mnt_opts will be NULL.
> Please help to double check, thanks!

I'd prefer something like:

If the hook returns 0, the caller is responsible for destroying the
returned @mnt_opts using the @sb_free_mnt_opts hook. The LSMs must not
expect the callers to destroy @mnt_opts if the hook returns an error
and should always set it to NULL in such case.

(You may want to double-check that the other implementations of this
hook (i.e. security/smack/smack_lsm.c) follow that contract and fix
them if necessary.)

Thanks for your efforts to improve this!

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.