it wont work on read-only container
On Friday, March 27th, 2026 at 8:47 PM, Qualys Security Advisory <[email protected]> wrote: > DuckDuckGo was unable to verify sender identity > > 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. > > Thank you very much in advance! We are at your disposal for questions, > comments, and further discussions. With best regards, > > -- > the Qualys Security Advisory team >
