In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix NULL pointer dereference in unixneedsrevalidation

When receiving file descriptors via SCMRIGHTS, both the socket pointer and the socket's sk pointer can be NULL during socket setup or teardown, causing NULL pointer dereferences in unixneedsrevalidation().

This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new unixneedsrevalidation() function was added without proper NULL checks.

The crash manifests as: BUG: kernel NULL pointer dereference, address: 0x0000000000000018 RIP: aafileperm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0) Call Trace: apparmorfilereceive+0x42/0x80 securityfilereceive+0x2e/0x50 receivefd+0x1d/0xf0 scmdetachfds+0xad/0x1c0

The function dereferences sock->sk->skfamily without checking if either sock or sock->sk is NULL first.

Add NULL checks for both sock and sock->sk before accessing skfamily.

On Thu, Mar 26, 2026 at 06:36:17PM +0000, Qualys Security Advisory wrote: Hi Linux kernel CVE assignment team, all,

We saw that last week you assigned two CVEs to two of the nine AppArmor vulnerabilities that were fixed and released on March 12, thank you very much for these:

------------------------------------------------------------------------ https://lore.kernel.org/linux-cve-announce/2026031846-CVE-2026-23268-6be3@gregkh/T/#u - "[PATCH 08/11] apparmor: fix unprivileged local user can do privileged policy management" (the confused-deputy problem detailed in this advisory); ------------------------------------------------------------------------ https://lore.kernel.org/linux-cve-announce/2026031846-CVE-2026-23269-2bf7@gregkh/T/#u - "[PATCH 01/11] apparmor: validate DFA start states are in bounds in unpackpdb" (an out-of-bounds read); ------------------------------------------------------------------------

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:

------------------------------------------------------------------------ https://git.kernel.org/stable/c/e38c55d9f834e5b848bfed0f5c586aaf45acb825 - "[PATCH 02/11] apparmor: fix memory leak in verifyheader" (a memory leak); Now assigned to CVE-2026-23403 ------------------------------------------------------------------------ https://git.kernel.org/stable/c/ab09264660f9de5d05d1ef4e225aa447c63a8747 CVE-2026-23404 https://git.kernel.org/stable/c/306039414932c80f8420695a24d4fe10c84ccfb2 CVE-2026-23405 - "[PATCH 03/11] apparmor: replace recursive profile removal with iterative approach" and "[PATCH 04/11] apparmor: fix: limit the number of levels of policy namespaces" (the uncontrolled recursion detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/8756b68edae37ff546c02091989a4ceab3f20abd CVE-2026-23406 - "[PATCH 05/11] apparmor: fix side-effect bug in matchchar() macro usage" (the out-of-bounds read detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/d352873bbefa7eb39995239d0b44ccdf8aaa79a4 CVE-2026-23407 - "[PATCH 06/11] apparmor: fix missing bounds check on DEFAULT table in verifydfa()" (an out-of-bounds read and write); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/5df0c44e8f5f619d3beb871207aded7c78414502 CVE-2026-23408 - "[PATCH 07/11] apparmor: Fix double free of nsname in aareplaceprofiles()" (the double-free detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/39440b137546a3aa383cfdabc605fb73811b6093 CVE-2026-23409 - "[PATCH 09/11] apparmor: fix differential encoding verification" (an infinite loop); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/a0b7091c4de45a7325c8780e6934a894f92ac86b CVE-2026-23410 https://git.kernel.org/stable/c/8e135b8aee5a06c52a4347a5a6d51223c6f36ba3 CVE-2026-23411

Hope that helps people's accounting systems :)

thanks,

greg k-h

On 3/28/26 23:18, Greg KH wrote: On Sat, Mar 28, 2026 at 02:41:23PM -0700, John Johansen wrote: 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 unprivilegedusernsapparmorpolicy 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. So do you feel the above CVE should be revoked, or that CVEs should be issued for all of the other commits as well? As much as I dislike it, with lxd/incus actively allowing use of policy namespaces. I think CVEs should probably be issued for the other commits as well.

On Sat, Mar 28, 2026 at 02:41:23PM -0700, John Johansen wrote: 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 unprivilegedusernsapparmorpolicy 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. So do you feel the above CVE should be revoked, or that CVEs should be issued for all of the other commits as well?

thanks,

greg k-h

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 unprivilegedusernsapparmorpolicy 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.

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:

------------------------------------------------------------------------ https://git.kernel.org/stable/c/e38c55d9f834e5b848bfed0f5c586aaf45acb825 - "[PATCH 02/11] apparmor: fix memory leak in verifyheader" (a memory leak); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/ab09264660f9de5d05d1ef4e225aa447c63a8747 https://git.kernel.org/stable/c/306039414932c80f8420695a24d4fe10c84ccfb2 - "[PATCH 03/11] apparmor: replace recursive profile removal with iterative approach" and "[PATCH 04/11] apparmor: fix: limit the number of levels of policy namespaces" (the uncontrolled recursion detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/8756b68edae37ff546c02091989a4ceab3f20abd - "[PATCH 05/11] apparmor: fix side-effect bug in matchchar() macro usage" (the out-of-bounds read detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/d352873bbefa7eb39995239d0b44ccdf8aaa79a4 - "[PATCH 06/11] apparmor: fix missing bounds check on DEFAULT table in verifydfa()" (an out-of-bounds read and write); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/5df0c44e8f5f619d3beb871207aded7c78414502 - "[PATCH 07/11] apparmor: Fix double free of nsname in aareplaceprofiles()" (the double-free detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/39440b137546a3aa383cfdabc605fb73811b6093 - "[PATCH 09/11] apparmor: fix differential encoding verification" (an infinite loop); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/a0b7091c4de45a7325c8780e6934a894f92ac86b https://git.kernel.org/stable/c/8e135b8aee5a06c52a4347a5a6d51223c6f36ba3 - "[PATCH 10/11] apparmor: fix race on rawdata dereference" and "[PATCH 11/11] apparmor: fix race between freeing data and fs accessing it" (the use-after-free detailed in this advisory). ------------------------------------------------------------------------

Thank you very much in advance! With best regards, 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.

thanks,

greg k-h

Hi Linux kernel CVE assignment team, all,

We saw that last week you assigned two CVEs to two of the nine AppArmor vulnerabilities that were fixed and released on March 12, thank you very much for these:

------------------------------------------------------------------------ https://lore.kernel.org/linux-cve-announce/2026031846-CVE-2026-23268-6be3@gregkh/T/#u - "[PATCH 08/11] apparmor: fix unprivileged local user can do privileged policy management" (the confused-deputy problem detailed in this advisory); ------------------------------------------------------------------------ https://lore.kernel.org/linux-cve-announce/2026031846-CVE-2026-23269-2bf7@gregkh/T/#u - "[PATCH 01/11] apparmor: validate DFA start states are in bounds in unpackpdb" (an out-of-bounds read); ------------------------------------------------------------------------

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:

------------------------------------------------------------------------ https://git.kernel.org/stable/c/e38c55d9f834e5b848bfed0f5c586aaf45acb825 - "[PATCH 02/11] apparmor: fix memory leak in verifyheader" (a memory leak); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/ab09264660f9de5d05d1ef4e225aa447c63a8747 https://git.kernel.org/stable/c/306039414932c80f8420695a24d4fe10c84ccfb2 - "[PATCH 03/11] apparmor: replace recursive profile removal with iterative approach" and "[PATCH 04/11] apparmor: fix: limit the number of levels of policy namespaces" (the uncontrolled recursion detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/8756b68edae37ff546c02091989a4ceab3f20abd - "[PATCH 05/11] apparmor: fix side-effect bug in matchchar() macro usage" (the out-of-bounds read detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/d352873bbefa7eb39995239d0b44ccdf8aaa79a4 - "[PATCH 06/11] apparmor: fix missing bounds check on DEFAULT table in verifydfa()" (an out-of-bounds read and write); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/5df0c44e8f5f619d3beb871207aded7c78414502 - "[PATCH 07/11] apparmor: Fix double free of nsname in aareplaceprofiles()" (the double-free detailed in this advisory); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/39440b137546a3aa383cfdabc605fb73811b6093 - "[PATCH 09/11] apparmor: fix differential encoding verification" (an infinite loop); ------------------------------------------------------------------------ https://git.kernel.org/stable/c/a0b7091c4de45a7325c8780e6934a894f92ac86b https://git.kernel.org/stable/c/8e135b8aee5a06c52a4347a5a6d51223c6f36ba3 - "[PATCH 10/11] apparmor: fix race on rawdata dereference" and "[PATCH 11/11] apparmor: fix race between freeing data and fs accessing it" (the use-after-free detailed in this advisory). ------------------------------------------------------------------------

Thank you very much in advance! With best regards,

-- the Qualys Security Advisory team

An issue was discovered in AppArmor before 2.12. Incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to the common logic to handle 'restart' operations removing AppArmor profiles that aren't found in the typical filesystem locations, such as /etc/apparmor.d/. Userspace projects that manage their own AppArmor profiles in atypical directories, such as what's done by LXD and Docker, are affected by this flaw in the AppArmor init script logic.

A vulnerability leading to a local privilege escalation was found in apparmor in the Linux kernel. When procpidattrwrite() was changed to use memdupuser apparmor's (interface violating) assumption that the setprocattr buffer was always a single page was violated.

Upstream pull request:

http://marc.info/?l=linux-kernel&m=146793642811929&w=2

Upstream fix:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30a46a4647fd1df9cf52e43bf467f0d9265096ca

References:

http://seclists.org/oss-sec/2016/q3/30