<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/security/apparmor/policy.c, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-13T16:20:48+00:00</updated>
<entry>
<title>apparmor: fix race on rawdata dereference</title>
<updated>2026-03-13T16:20:48+00:00</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2026-02-24T18:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9761add6d100962a23996cb68f3d6abdd4d1815'/>
<id>urn:sha1:f9761add6d100962a23996cb68f3d6abdd4d1815</id>
<content type='text'>
commit a0b7091c4de45a7325c8780e6934a894f92ac86b upstream.

There is a race condition that leads to a use-after-free situation:
because the rawdata inodes are not refcounted, an attacker can start
open()ing one of the rawdata files, and at the same time remove the
last reference to this rawdata (by removing the corresponding profile,
for example), which frees its struct aa_loaddata; as a result, when
seq_rawdata_open() is reached, i_private is a dangling pointer and
freed memory is accessed.

The rawdata inodes weren't refcounted to avoid a circular refcount and
were supposed to be held by the profile rawdata reference.  However
during profile removal there is a window where the vfs and profile
destruction race, resulting in the use after free.

Fix this by moving to a double refcount scheme. Where the profile
refcount on rawdata is used to break the circular dependency. Allowing
for freeing of the rawdata once all inode references to the rawdata
are put.

Fixes: 5d5182cae401 ("apparmor: move to per loaddata files, instead of replicating in profiles")
Reported-by: Qualys Security Advisory &lt;qsa@qualys.com&gt;
Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Reviewed-by: Maxime Bélair &lt;maxime.belair@canonical.com&gt;
Reviewed-by: Cengiz Can &lt;cengiz.can@canonical.com&gt;
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: fix unprivileged local user can do privileged policy management</title>
<updated>2026-03-13T16:20:48+00:00</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2025-11-07T16:36:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fc63dd9170643d15c25681fca792539e23f4640'/>
<id>urn:sha1:0fc63dd9170643d15c25681fca792539e23f4640</id>
<content type='text'>
commit 6601e13e82841879406bf9f369032656f441a425 upstream.

An unprivileged local user can load, replace, and remove profiles by
opening the apparmorfs interfaces, via a confused deputy attack, by
passing the opened fd to a privileged process, and getting the
privileged process to write to the interface.

This does require a privileged target that can be manipulated to do
the write for the unprivileged process, but once such access is
achieved full policy management is possible and all the possible
implications that implies: removing confinement, DoS of system or
target applications by denying all execution, by-passing the
unprivileged user namespace restriction, to exploiting kernel bugs for
a local privilege escalation.

The policy management interface can not have its permissions simply
changed from 0666 to 0600 because non-root processes need to be able
to load policy to different policy namespaces.

Instead ensure the task writing the interface has privileges that
are a subset of the task that opened the interface. This is already
done via policy for confined processes, but unconfined can delegate
access to the opened fd, by-passing the usual policy check.

Fixes: b7fd2c0340eac ("apparmor: add per policy ns .load, .replace, .remove interface files")
Reported-by: Qualys Security Advisory &lt;qsa@qualys.com&gt;
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Reviewed-by: Cengiz Can &lt;cengiz.can@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: Fix double free of ns_name in aa_replace_profiles()</title>
<updated>2026-03-13T16:20:48+00:00</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2025-09-10T13:22:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=86feeccd6b93ed94bd6655f30de80f163f8d5a45'/>
<id>urn:sha1:86feeccd6b93ed94bd6655f30de80f163f8d5a45</id>
<content type='text'>
commit 5df0c44e8f5f619d3beb871207aded7c78414502 upstream.

if ns_name is NULL after
1071         error = aa_unpack(udata, &amp;lh, &amp;ns_name);

and if ent-&gt;ns_name contains an ns_name in
1089                 } else if (ent-&gt;ns_name) {

then ns_name is assigned the ent-&gt;ns_name
1095                         ns_name = ent-&gt;ns_name;

however ent-&gt;ns_name is freed at
1262                 aa_load_ent_free(ent);

and then again when freeing ns_name at
1270         kfree(ns_name);

Fix this by NULLing out ent-&gt;ns_name after it is transferred to ns_name

Fixes: 145a0ef21c8e9 ("apparmor: fix blob compression when ns is forced on a policy load")
Reported-by: Qualys Security Advisory &lt;qsa@qualys.com&gt;
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Reviewed-by: Cengiz Can &lt;cengiz.can@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: replace recursive profile removal with iterative approach</title>
<updated>2026-03-13T16:20:47+00:00</updated>
<author>
<name>Massimiliano Pellizzer</name>
<email>massimiliano.pellizzer@canonical.com</email>
</author>
<published>2026-01-13T08:09:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=999bd704b0b641527a5ed46f0d969deff8cfa68b'/>
<id>urn:sha1:999bd704b0b641527a5ed46f0d969deff8cfa68b</id>
<content type='text'>
commit ab09264660f9de5d05d1ef4e225aa447c63a8747 upstream.

The profile removal code uses recursion when removing nested profiles,
which can lead to kernel stack exhaustion and system crashes.

Reproducer:
  $ pf='a'; for ((i=0; i&lt;1024; i++)); do
      echo -e "profile $pf { \n }" | apparmor_parser -K -a;
      pf="$pf//x";
  done
  $ echo -n a &gt; /sys/kernel/security/apparmor/.remove

Replace the recursive __aa_profile_list_release() approach with an
iterative approach in __remove_profile(). The function repeatedly
finds and removes leaf profiles until the entire subtree is removed,
maintaining the same removal semantic without recursion.

Fixes: c88d4c7b049e ("AppArmor: core policy routines")
Reported-by: Qualys Security Advisory &lt;qsa@qualys.com&gt;
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Reviewed-by: Cengiz Can &lt;cengiz.can@canonical.com&gt;
Signed-off-by: Massimiliano Pellizzer &lt;massimiliano.pellizzer@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: allocate xmatch for nullpdb inside aa_alloc_null</title>
<updated>2025-01-23T16:23:05+00:00</updated>
<author>
<name>Ryan Lee</name>
<email>ryan.lee@canonical.com</email>
</author>
<published>2024-08-21T18:01:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c3f731b253b3454a0fd3d20351c823dd1dea933'/>
<id>urn:sha1:4c3f731b253b3454a0fd3d20351c823dd1dea933</id>
<content type='text'>
commit 17d0d04f3c999e7784648bad70ce1766c3b49d69 upstream.

attach-&gt;xmatch was not set when allocating a null profile, which is used in
complain mode to allocate a learning profile. This was causing downstream
failures in find_attach, which expected a valid xmatch but did not find
one under a certain sequence of profile transitions in complain mode.

This patch ensures the xmatch is set up properly for null profiles.

Signed-off-by: Ryan Lee &lt;ryan.lee@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Cc: Paul Kramme &lt;kramme@digitalmanufaktur.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: use kvfree_sensitive to free data-&gt;data</title>
<updated>2024-05-10T15:32:35+00:00</updated>
<author>
<name>Fedor Pchelkin</name>
<email>pchelkin@ispras.ru</email>
</author>
<published>2024-02-01T14:24:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2bc73505a5cd2a18a7a542022722f136c19e3b87'/>
<id>urn:sha1:2bc73505a5cd2a18a7a542022722f136c19e3b87</id>
<content type='text'>
Inside unpack_profile() data-&gt;data is allocated using kvmemdup() so it
should be freed with the corresponding kvfree_sensitive().

Also add missing data-&gt;data release for rhashtable insertion failure path
in unpack_profile().

Found by Linux Verification Center (linuxtesting.org).

Fixes: e025be0f26d5 ("apparmor: support querying extended trusted helper extra data")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin &lt;pchelkin@ispras.ru&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
</content>
</entry>
<entry>
<title>apparmor: free the allocated pdb objects</title>
<updated>2024-01-03T19:48:02+00:00</updated>
<author>
<name>Fedor Pchelkin</name>
<email>pchelkin@ispras.ru</email>
</author>
<published>2023-11-27T17:59:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1af5aa82c976753e93eb52b72784e586a7d2844b'/>
<id>urn:sha1:1af5aa82c976753e93eb52b72784e586a7d2844b</id>
<content type='text'>
policy_db objects are allocated with kzalloc() inside aa_alloc_pdb() and
are not cleared in the corresponding aa_free_pdb() function causing leak:

unreferenced object 0xffff88801f0a1400 (size 192):
  comm "apparmor_parser", pid 1247, jiffies 4295122827 (age 2306.399s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff81ddc612&gt;] __kmem_cache_alloc_node+0x1e2/0x2d0
    [&lt;ffffffff81c47c55&gt;] kmalloc_trace+0x25/0xc0
    [&lt;ffffffff83eb9a12&gt;] aa_alloc_pdb+0x82/0x140
    [&lt;ffffffff83ec4077&gt;] unpack_pdb+0xc7/0x2700
    [&lt;ffffffff83ec6b10&gt;] unpack_profile+0x450/0x4960
    [&lt;ffffffff83ecc129&gt;] aa_unpack+0x309/0x15e0
    [&lt;ffffffff83ebdb23&gt;] aa_replace_profiles+0x213/0x33c0
    [&lt;ffffffff83e8d341&gt;] policy_update+0x261/0x370
    [&lt;ffffffff83e8d66e&gt;] profile_replace+0x20e/0x2a0
    [&lt;ffffffff81eadfaf&gt;] vfs_write+0x2af/0xe00
    [&lt;ffffffff81eaf4c6&gt;] ksys_write+0x126/0x250
    [&lt;ffffffff890fa0b6&gt;] do_syscall_64+0x46/0xf0
    [&lt;ffffffff892000ea&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76

Free the pdbs inside aa_free_pdb(). While at it, rename the variable
representing an aa_policydb object to make the function more unified with
aa_pdb_free_kref() and aa_alloc_pdb().

Found by Linux Verification Center (linuxtesting.org).

Fixes: 98b824ff8984 ("apparmor: refcount the pdb")
Signed-off-by: Fedor Pchelkin &lt;pchelkin@ispras.ru&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
</content>
</entry>
<entry>
<title>apparmor: Fix some kernel-doc comments</title>
<updated>2023-10-23T07:26:27+00:00</updated>
<author>
<name>Yang Li</name>
<email>yang.lee@linux.alibaba.com</email>
</author>
<published>2023-10-23T01:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6cede10161be00d129a24e8b84c2674785a32cf8'/>
<id>urn:sha1:6cede10161be00d129a24e8b84c2674785a32cf8</id>
<content type='text'>
Fix some kernel-doc comments to silence the warnings:
security/apparmor/policy.c:117: warning: Function parameter or member 'kref' not described in 'aa_pdb_free_kref'
security/apparmor/policy.c:117: warning: Excess function parameter 'kr' description in 'aa_pdb_free_kref'
security/apparmor/policy.c:882: warning: Function parameter or member 'subj_cred' not described in 'aa_may_manage_policy'

Reported-by: Abaci Robot &lt;abaci@linux.alibaba.com&gt;
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7037
Signed-off-by: Yang Li &lt;yang.lee@linux.alibaba.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
</content>
</entry>
<entry>
<title>apparmor: allow restricting unprivileged change_profile</title>
<updated>2023-10-18T22:48:44+00:00</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2023-08-09T07:26:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d9da9b188b8cd3b579d7ef5ba5d334be9dd38fc'/>
<id>urn:sha1:2d9da9b188b8cd3b579d7ef5ba5d334be9dd38fc</id>
<content type='text'>
unprivileged unconfined can use change_profile to alter the confinement
set by the mac admin.

Allow restricting unprivileged unconfined by still allowing change_profile
but stacking the change against unconfined. This allows unconfined to
still apply system policy but allows the task to enter the new confinement.

If unprivileged unconfined is required a sysctl is provided to switch
to the previous behavior.

Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
</content>
</entry>
<entry>
<title>apparmor: refcount the pdb</title>
<updated>2023-10-18T22:30:47+00:00</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2023-04-28T12:32:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98b824ff8984fd523fc264fbb13208098ab09da3'/>
<id>urn:sha1:98b824ff8984fd523fc264fbb13208098ab09da3</id>
<content type='text'>
With the move to permission tables the dfa is no longer a stand
alone entity when used, needing a minimum of a permission table.
However it still could be shared among different pdbs each using
a different permission table.

Instead of duping the permission table when sharing a pdb, add a
refcount to the pdb so it can be easily shared.

Reviewed-by: Georgia Garcia &lt;georgia.garcia@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
</content>
</entry>
</feed>
