apparmor: fix race condition in null profile creation

There is a race when null- profile is being created between the
initial lookup/creation of the profile and lock/addition of the
profile. This could result in multiple version of a profile being
added to the list which need to be removed/replaced.

Since these are learning profile their is no affect on mediation.

Signed-off-by: John Johansen <john.johansen@canonical.com>
This commit is contained in:
John Johansen 2017-08-16 05:40:49 -07:00
parent d07881d2ed
commit 290638a52a
1 changed files with 11 additions and 3 deletions

View File

@ -500,7 +500,8 @@ struct aa_profile *aa_fqlookupn_profile(struct aa_label *base,
struct aa_profile *aa_new_null_profile(struct aa_profile *parent, bool hat, struct aa_profile *aa_new_null_profile(struct aa_profile *parent, bool hat,
const char *base, gfp_t gfp) const char *base, gfp_t gfp)
{ {
struct aa_profile *profile; struct aa_profile *p, *profile;
const char *bname;
char *name; char *name;
AA_BUG(!parent); AA_BUG(!parent);
@ -523,7 +524,8 @@ struct aa_profile *aa_new_null_profile(struct aa_profile *parent, bool hat,
name: name:
/* lookup to see if this is a dup creation */ /* lookup to see if this is a dup creation */
profile = aa_find_child(parent, basename(name)); bname = basename(name);
profile = aa_find_child(parent, bname);
if (profile) if (profile)
goto out; goto out;
@ -544,7 +546,13 @@ name:
profile->policy.dfa = aa_get_dfa(nulldfa); profile->policy.dfa = aa_get_dfa(nulldfa);
mutex_lock(&profile->ns->lock); mutex_lock(&profile->ns->lock);
__add_profile(&parent->base.profiles, profile); p = __find_child(&parent->base.profiles, bname);
if (p) {
aa_free_profile(profile);
profile = aa_get_profile(p);
} else {
__add_profile(&parent->base.profiles, profile);
}
mutex_unlock(&profile->ns->lock); mutex_unlock(&profile->ns->lock);
/* refcount released by caller */ /* refcount released by caller */