Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220128202858.96935-1-vbendel@redhat.com> <20220128202858.96935-2-vbendel@redhat.com>
 <CAHC9VhR78VGMPLv1xBRQEqzaPjJa_KvFE8OLmHa6J2pjaG6m1w@mail.gmail.com>
In-Reply-To: <CAHC9VhR78VGMPLv1xBRQEqzaPjJa_KvFE8OLmHa6J2pjaG6m1w@mail.gmail.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Tue, 1 Feb 2022 15:09:49 -0500
Message-ID: <CAHC9VhRkL++m_jkqK+0D2rXc_LMbkH1SSFGmAJiGEeDu6rA-xQ@mail.gmail.com>
Subject: Re: [PATCH 1/3] selinux: consistently clear cond_list on error paths
To:     vbendel@redhat.com
Cc:     stephen.smalley.work@gmail.com, eparis@parisplace.org,
        omosnace@redhat.com, selinux@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 1, 2022 at 12:38 PM Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Jan 28, 2022 at 3:29 PM <vbendel@redhat.com> wrote:
> > From: Vratislav Bendel <vbendel@redhat.com>
> >
> > Currently there are two users of policydb->cond_list: cond_read_list()
> > and duplicate_policydb_cond_list(). On their error path one clears
> > ->cond_list to NULL, but the other doesn't.
> > Make the behavior consistent by resetting ->cond_list to NULL in
> > cond_list_destroy(), which is called by both on the error path.
>
> It's also important to see if there are any callers of
> cond_list_destroy() which incorrectly might be making use of
> policydb::cond_list after it has been freed; thankfully that does not
> appear to be the case in any of the call paths I looked at just now.
> As this is more a a style/Right-Thing-To-Do patch and not an immediate
> bugfix I'm going to go and merge this into selinux/next.

After looking at patches 2/3 and 3/3, ignore the last sentence above
and see my comments below :)

> Thanks Vratislav.
>
> > Signed-off-by: Vratislav Bendel <vbendel@redhat.com>
> > ---
> >  security/selinux/ss/conditional.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/security/selinux/ss/conditional.c b/security/selinux/ss/conditional.c
> > index 2ec6e5cd25d9..1d0e5f326b62 100644
> > --- a/security/selinux/ss/conditional.c
> > +++ b/security/selinux/ss/conditional.c
> > @@ -152,6 +152,7 @@ static void cond_list_destroy(struct policydb *p)
> >         for (i = 0; i < p->cond_list_len; i++)
> >                 cond_node_destroy(&p->cond_list[i]);
> >         kfree(p->cond_list);
> > +       p->cond_list = NULL;

While patch 1/3 may not be a candidate for selinux/stable-5.17 by
itself, patch 2/3 definitely qualifies.  Considering that both patches
are small, easily understood, and the likelihood of a merge conflict
between the two is high, why don't you squash 1/3 and 2/3 together so
we can submit this for selinux/stable-5.17?  In addition, put the two
lines which reset cond_list and cond_list_len together in v2, it's
cleaner that way, example below.  If you don't have time to do that
let me know and I can squash them together and move the
"p->cond_list_len = 0" line (don't worry, I'll preserve your
name/email as the patch author).

  static void cond_list_destroy(...)
  {

    /* ... */

    kfree(p->cond_list);
    p->cond_list = NULL;
    p->cond_list_len = 0;
  }

> >  }
> >
> >  void cond_policydb_destroy(struct policydb *p)
> > @@ -441,7 +442,6 @@ int cond_read_list(struct policydb *p, void *fp)
> >         return 0;
> >  err:
> >         cond_list_destroy(p);
> > -       p->cond_list = NULL;
> >         return rc;
> >  }

-- 
paul-moore.com