Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2026032823-outspoken-haven-c701@gregkh>
Date: Sat, 28 Mar 2026 06:55:08 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Qualys Security Advisory <qsa@...lys.com>
Cc: John Johansen <john.johansen@...onical.com>,
	"cve@...nel.org" <cve@...nel.org>,
	"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Multiple vulnerabilities in AppArmor

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.

thanks,

greg k-h

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.