[SRU][P][PATCH v3 0/1] kernel panic when reloading apparmor 5.0.0 profiles

Mehmet Basaran mehmet.basaran at canonical.com
Wed Aug 13 07:56:37 UTC 2025


SRU Justification:

[Impact]

Profile loads containing the attach_disconnected.path policy flag can cause the kernel to panic if such a profile is loaded into the kernel and subsequently replaced or removed.

[Fix]

Apply attached patch
UBUNTU: SAUCE: apparmor5.0.0 [94/93]: apparmor: prevent pro file->disconnected double free in aa_free_profile

[Test Plan]

download attached file trigger-lp2120233.profile and run the following script.
The loop is not necessarily needed to trigger the bug, it will often trigger
immediately. However because it is a double free, unless memory debugging is enable it may not trigger immediately. Looping however can reliably trigger it.

for i in 1 2 3 4 5; do ;
   sudo apparmor_parser -r trigger-lp2120233.profile
   sudo apparmor_parser -R trigger-lp2120233.profile
done

The apparmor_parser -R step will trigger the a kernel ops/panic. If the kernel is patched there shouldn't be an oops.

[Where problems could occur]

The bug can be triggered by any action that replaces a profile with the
attach_disconnected.path policy flag. Currently this would be:
- the lsof profile in apparmor 5.0
- custom created profiles containing the attach_disconnected.path policy flag.

Once a profile with the above flag is set. Any action causing profile replacement/removal of the profile will trigger the bug. This includes

- manually replacing/removing profiles via the apparmor_parser
- systemctl restart apparmor
- upgrading apparmor_5.0.0~alpha1-0ubuntu1 to an apparmor_package that is
   not aware of the issue.
- release upgrading between plucky & questing if a profile with the problematic attach_disconnected.path policy flag has been loaded (not the case with default policy).
- running the qa-regression-testing suit

[Other Info]

Installing, or upgrading the kernel should not cause the bug to trigger.

Shutting down, or reboot the system should not trigger the bug because apparmor does not unload profiles during systemctl stop apparmor.

This bug can be triggered by the qa-regression-testing suit. If a profile containing attach_disconnected.path is present in /etc/apparmor.d/ even when the profile is disabled because the qa-regression-testing suit will attempt to enable and test all disabled profiles.

There is a separate fix being applied to qa-regression-testing to ensure it doesn't trigger this bug.

Originally John Johansen <john.johansen at canonical.com> sent this patch.

Mehmet Basaran (1):
  UBUNTU: SAUCE: apparmor5.0.0 [94/93]: apparmor: prevent
    profile->disconnected double free in aa_free_profile

 security/apparmor/policy.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--
2.43.0



More information about the kernel-team mailing list