[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f8de07b7-edc8-4ffb-ba71-612ad1e0ab80@canonical.com>
Date: Sat, 28 Mar 2026 14:41:23 -0700
From: John Johansen <john.johansen@...onical.com>
To: Greg KH <gregkh@...uxfoundation.org>,
Qualys Security Advisory <qsa@...lys.com>
Cc: "cve@...nel.org" <cve@...nel.org>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Multiple vulnerabilities in AppArmor
On 3/27/26 22:55, Greg KH wrote:
> On Fri, Mar 27, 2026 at 02:50:42PM +0000, Qualys Security Advisory wrote:
>> Hi Greg, John, all,
>>
>> On Fri, Mar 27, 2026 at 07:23:24AM +0100, Greg KH wrote:
>>> On Thu, Mar 26, 2026 at 06:36:17PM +0000, Qualys Security Advisory wrote:
>>>> Since two weeks have passed now (since the fixes were released), would
>>>> it be possible to please assign CVEs to the remaining seven AppArmor
>>>> vulnerabilities:
>>> We were told that these all required elevated privileges to hit, and so
>>> were not classified as individual vulnerabilities. If the Apparmor
>>> maintainer tells us that these really all should be assigned a CVE, we
>>> will be glad to do so, but until then, we're just going to stick with
>>> the ones that we have assigned already.
>>
>> Thank you very much for your reply! Adding John Johansen then
>> (AppArmor's maintainer), since he will have the authoritative answer.
>>
>> The problem is that containers can be allowed to manage their own
>> AppArmor profiles (via AppArmor namespaces), in which case an attacker
>> inside such a container can directly write to AppArmor's .load, .replace
>> and .remove files and trigger all these vulnerabilities, even without
>> CVE-2026-23268 (the confused-deputy vulnerability).
>>
>> The way we see it:
>>
>> - either CVEs should be assigned to the remaining seven vulnerabilities,
>> in light of the container use case described above;
>>
>> - or CVE-2026-23269 ("validate DFA start states are in bounds") should
>> be rejected, because this vulnerability is no different from the other
>> seven vulnerabilities.
>
> Looks like this one should be rejected, but I will defer to John as to
> what he wishes to have done here, as he is the maintainer of this part
> of the kernel.
>
It is possible to exploit from a user namespace under the correct
circumstances. Specifically
A privileged process must do the setup, such that it creates a policy
namespace (requires administrative privileges) and ties the "root"
process of the user namespace to the the policy namespace. The "root"
user of the user namespace, then has privilege to load policy to the
policy namespace tied to the container. The root user of the container
could then use the policy load bugs to attack the kernel.
Incus/LXD can setup a policy namespace for a container, the patch
allowing LXD to do this is what introduced the LPE.
Without the LPE a regular user, or even root in a user namespace
can not use the other bugs to attack the kernel, except in the
case outlined above where a privileged process setups a policy
namespace and ties it to the container.
I should also note there is an easy mitigation for the container
case. Sysadmins can set the sysctl unprivileged_userns_apparmor_policy
to false. This will stop root within the container from being able
to load policy even when the policy namespace is tied to the user
namespace.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
