| Submitter | John Johansen |
|---|---|
| Date | Nov. 9, 2009, 8:41 p.m. |
| Message ID | <1257799316-12573-2-git-send-email-john.johansen@canonical.com> |
| Download | mbox | patch |
| Permalink | /patch/38036/ |
| State | Superseded |
| Headers | show |
Comments
Patch
diff --git a/ubuntu/apparmor/policy.c b/ubuntu/apparmor/policy.c index 390bbf6..a772801 100644 --- a/ubuntu/apparmor/policy.c +++ b/ubuntu/apparmor/policy.c @@ -322,7 +322,7 @@ void __aa_remove_profile(struct aa_profile *profile, if (replacement) profile->replacedby = aa_get_profile(replacement); else - profile->replacedby = ERR_PTR(-EINVAL); + profile->replacedby = aa_get_profile(profile->ns->unconfined); list_del_init(&profile->base.list); if (!(profile->flags & PFLAG_NO_LIST_REF)) aa_put_profile(profile);
BugLink: http://bugs.launchpad.net/bugs/475619 Profile removal results in child profiles having their replacedby field assigned an ERR_PTR. Which will cause a null pointer oops. This will affect any application that has a profile in a hat, or a learning mode subprofile when the base profile is removed. The use of ERR_PTR used to be the way AppArmor would distinguish between a removal and unconfined, this became invalid when the namespace->unconfined profile was introduced. After replacement the child process will change its context so that its profile is set ERR_PTR, the ERR_PTR then gets filtered to a NULL ptr which then causes the oops. Signed-off-by: John Johansen <john.johansen@canonical.com> --- ubuntu/apparmor/policy.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)