NACK/Cmnt: [SRU][Xenial][PATCH 0/1] Fix memory leak on profile removal

[Stefan Bader]

On 16.08.21 14:23, Georgia Garcia wrote:
> On Mon, 2021-08-16 at 09:21 +0200, Stefan Bader wrote:
>> On 13.08.21 21:07, Georgia Garcia wrote:
>>> BugLink: https://bugs.launchpad.net/bugs/1939915
>>>
>>> SRU Justification:
>>>
>>> [Impact]
>>> There's a memory leak on AppArmor when removing a profile. When the
>>> proxy isn't replaced and the profile is removed, the proxy is leaked.
>>>
>>> [Fix]
>>>
>>> Upstream commit 3622ad25d4d fixes the leak by cleaning up the label
>>> structure within the profile when the profile is getting freed. The
>>> proxy is freed correctly when cleaning up the label.
>>>
>>> [Test Plan]
>>>
>>> /sys/kernel/debug/kmemleak should not return a memleak when removing
>>> a profile.
>>>
>>> root at ubuntu:~# echo "profile foo {}" > profile
>>> root at ubuntu:~# apparmor_parser profile
>>> root at ubuntu:~# echo scan > /sys/kernel/debug/kmemleak
>>> root at ubuntu:~# cat /sys/kernel/debug/kmemleak
>>>
>>> [Where problems could occur]
>>> Low probability of any problem. There's no longer a leak.
>>>
>>>
>>> John Johansen (1):
>>>     apparmor: Fix memory leak of profile proxy
>>>
>>>    security/apparmor/include/label.h |  1 +
>>>    security/apparmor/label.c         | 16 +++++++---------
>>>    security/apparmor/policy.c        |  1 +
>>>    3 files changed, 9 insertions(+), 9 deletions(-)
>>>
>> This was submitted for X and B/F and apparently it is all the same patch.
> 
> Yes, they all are cherry-picked from the same upstream commit, but the
> patch for F does not apply cleanly in B and vice versa.

Then it is not a cherry-pick but a backport of the upstream patch. Probably in 
both cases but maybe for different reasons. That is why you will see short 
explanations about what had to be changed for those backport patches.

> 
>> But
>> Xenial is ESM and those are handled on a different mailing list. And B/F should
>> be a single thread submission.
> 
> Just to be clear, does that mean that I should send the patch for B and
> the patch for F in a single thread submission?

Like it is done a lot on this list. A cover email for "SRU B/F 0/1" and followed 
by something like [PATCH B 1/1] + [PATCH F 1/1] in those cases where patches are 
different. At least that gives a chance to have a patch only once if it applies 
to multiple series.

-Stefan
> 
> Thanks,
> Georgia
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210816/e434762e/attachment.sig>