| Message ID | 20220128202858.96935-2-vbendel@redhat.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | selinux: Fix and clean policydb->cond_list error paths | expand |
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. 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; > } > > 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; > } > > -- > 2.26.3
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; > > }
On Tue, Feb 1, 2022 at 9:10 PM Paul Moore <paul@paul-moore.com> wrote: > > 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). I was also wondering about the possible conflict for submission into stable. I see no problem with squashing 1/3 and 2/3 together. I'll send the v2, as per your suggestions. :) Thank you and have a nice day! > > 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 >
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; } 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; }