Message ID | 4D78F83F.7070109@canonical.com |
---|---|
State | New |
Headers | show |
On 03/10/2011 05:11 PM, Paolo Pisati wrote: > SRU Justification: > > Impact: kernel panic when loading a malformed apparmor profile. > Fix: see attached patch. > Testcase: /etc/init.d/apparmor restart > > > Buglink: > https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/732700 > > This affetcs lucid/master, lucid/mvl-dove and maverick/mvl-dove. > > This fix a regression in the lucid/mvl-dove -proposed kernel. > > bye, > p Look reasonable. Personally I would add a bit more description into the commit message. Also as apparmor is upstream now and apparently is not affected I would wonder (without too much research on my own) why this is and whether there would be a equivalent upstream patch... Ackish, but interested in more info. -Stefan
On 03/10/2011 04:11 PM, Paolo Pisati wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > SRU Justification: > > Impact: kernel panic when loading a malformed apparmor profile. > Fix: see attached patch. > Testcase: /etc/init.d/apparmor restart > > > Buglink: > https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/732700 > > This affetcs lucid/master, lucid/mvl-dove and maverick/mvl-dove. > > This fix a regression in the lucid/mvl-dove -proposed kernel. > > bye, > p > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNePg/AAoJEMupOQaAohtUSQEH/1PcnD0apOvdM4WFt0G2fOwz > 2ZMT89kPoytAmYu3FSdICiXWJUKhFkQHEyou+RhkBmNrXjmT/JW9v16LTsAOUxBx > vWjlbeU8KZ0hpNfxF4lZQJBe9CmVgzP6OM48fvz01NLhhahUF8VmEDyGAIxQJq+h > E5vMLzVBYTWvyapRee7KV+mNzWJAMVXbSRfKtKg2s3Cx5yCpwzFWdghAept2nPvO > 1qAWIGhZfWcId5r8IV8Gqj+Yp1FifJkZMd06TT6/QFogJdGtjgdGps/e+4zshHsB > pDMDk3xLNA0c6bm6Dgnw5n9CV9bRl+jQ00Lzohk38ukQwzj+q16zy411zXKLuxA= > =pmpz > -----END PGP SIGNATURE----- > Acked-by: Tim Gardner <tim.gardner@canonical.com> Its worth noting that this regression has never been discovered on Maverick 'cause clearly no-one is using mvl-dove on Maverick. rtg
On 03/10/2011 09:20 AM, Stefan Bader wrote: > On 03/10/2011 05:11 PM, Paolo Pisati wrote: >> SRU Justification: >> >> Impact: kernel panic when loading a malformed apparmor profile. >> Fix: see attached patch. >> Testcase: /etc/init.d/apparmor restart >> >> >> Buglink: >> https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/732700 >> >> This affetcs lucid/master, lucid/mvl-dove and maverick/mvl-dove. >> >> This fix a regression in the lucid/mvl-dove -proposed kernel. >> >> bye, >> p > Look reasonable. Personally I would add a bit more description into the commit > message. Also as apparmor is upstream now and apparently is not affected I would > wonder (without too much research on my own) why this is and whether there would > be a equivalent upstream patch... > > Ackish, but interested in more info. > This brings the code in line with what is upstream. However this appears to have been fixed in the series of commits, cleaning up the code, making sure vars were zeroed out etc, and was never actually identified as a bug. It prevents the oops by ensuring the new_profile is null when it passes through the cleanup block at the end of the function which does aa_put_profile(new_profile); This will put the kfree and call free on the object unless it is null. Acked-by: John Johansen <john.johansen@canonical.com>
On 03/10/2011 06:39 PM, Tim Gardner wrote: > On 03/10/2011 04:11 PM, Paolo Pisati wrote: > SRU Justification: > > Impact: kernel panic when loading a malformed apparmor profile. > Fix: see attached patch. > Testcase: /etc/init.d/apparmor restart > > > Buglink: > https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/732700 > > This affetcs lucid/master, lucid/mvl-dove and maverick/mvl-dove. > > This fix a regression in the lucid/mvl-dove -proposed kernel. > > bye, > p >> > Acked-by: Tim Gardner <tim.gardner@canonical.com> > Its worth noting that this regression has never been discovered on Maverick > 'cause clearly no-one is using mvl-dove on Maverick. > rtg Actually it is probably worth mentioning that this is likely not a problem in Maverick because dml-dove on Maverick is based on Lucid. Which brings me to one more note: On future SRUs I would not mention the topic branches at all if the problem is in a master tree. All those will get the fix anyway when they are rebased. And it can be a pain to think of all of them. For example Lucid-ec2 will be affected by this bug, too. For branch specific SRU requests, I would include that in the subject, eg. [lucid-mvl-dove] SRU: ... At least to me this helps a lot to know at a glance what the target of a patch is (which comes handy later when applying). I have taken the liberty of extending the commit message by a bit more explanation and applied and pushed it to lucid-master-next. -Stefan
Applied and pushed to lucid master-next (only!) with slight extension of the description body. Affected topic branches will be updated when they get rebased.
From 7bb336c3ec41400853a5130870206dcc08849572 Mon Sep 17 00:00:00 2001 From: Paolo Pisati <paolo.pisati@canonical.com> Date: Thu, 10 Mar 2011 16:42:41 +0100 Subject: [PATCH] UBUNTU: SAUCE: Clear new_profile in error path BugLink: http://bugs.launchpad.net/bugs/732700 Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> --- security/apparmor/policy.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c index 61f0043..e1db319 100644 --- a/security/apparmor/policy.c +++ b/security/apparmor/policy.c @@ -922,6 +922,7 @@ ssize_t aa_interface_replace_profiles(void *udata, size_t size, bool add_only) new_profile = aa_unpack(udata, size, &sa); if (IS_ERR(new_profile)) { sa.base.error = PTR_ERR(new_profile); + new_profile = NULL; goto fail; } -- 1.7.1