linux.git/security/apparmor/include, branch v7.2-rc1

apparmor: fix kernel-doc warnings

2026-06-14T03:20:13+00:00

Fix two kernel-doc warnings:
- non-kernel-doc comment marked with '/**' in af_unix.c
- documented symbol name mismatch for aa_get_i_loaddata() in
  policy_unpack.h

No functional changes.

Signed-off-by: Rodrigo Zaiden 
Signed-off-by: John Johansen

apparmor: fix use-after-free in rawdata dedup loop

2026-06-14T03:20:13+00:00

aa_replace_profiles() walks ns->rawdata_list to dedup the incoming
policy blob against entries already attached to existing profiles.
Per the kernel-doc on struct aa_loaddata, list membership does not
hold a reference: profiles hold pcount, and when the last pcount
drops, do_ploaddata_rmfs() is queued on a workqueue that takes
ns->lock and removes the entry. Between dropping the last pcount
and the workqueue running, an entry remains on the list with
pcount == 0.

aa_get_profile_loaddata() is an unconditional kref_get() on
pcount, so when the dedup loop hits such an entry, refcount
hardening reports

  refcount_t: addition on 0; use-after-free.

inside aa_replace_profiles(), and the poisoned counter then
trips "saturated" and "underflow" warnings on the subsequent
uses of the same loaddata.

Before commit a0b7091c4de4 ("apparmor: fix race on rawdata
dereference") the dedup path used a get_unless_zero-style helper
on a single counter, so the existing "if (tmp)" guard was
meaningful. The split-refcount refactor introduced
aa_get_profile_loaddata(), which has plain kref_get() semantics,
and the guard quietly became a no-op.

Introduce aa_get_profile_loaddata_not0(), matching the existing
_not0 convention used by aa_get_profile_not0(), and use it for
the rawdata_list dedup lookup so dying entries are skipped.

Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu
24.04 + stress-ng 0.17.06:

  stress-ng --apparmor 1 --klog-check --timeout 60s

Without this patch the three refcount_t warnings fire within a
few seconds. With it the same 60 s run is clean. Coverage is a
smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN
and CONFIG_PROVE_LOCKING would be welcome from anyone with the
cycles.

Fixes: a0b7091c4de4 ("apparmor: fix race on rawdata dereference")
Reported-by: Colin Ian King 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221513
Cc: stable@vger.kernel.org
Signed-off-by: Ruslan Valiyev 
Signed-off-by: John Johansen

apparmor: remove or add symlinks to rawdata according to export_binary

2026-06-14T03:14:07+00:00

When the export_binary parameter is set, then rawdata is available and
there should be a symbolic link for the rawdata in the profile
directory in apparmorfs. If the parameter is unset, then the symlinks
should not exist.

The issue arises when changing the value of export_binary on runtime
and replacing profiles. If export_binary was set when the profile was
originally loaded, then changed to 0 and the profile was reloaded,
then the symbolic links would still exist but would return ENOENT
because the rawdata no longer exists.

On the opposite side, if export_binary was unset when the profile was
originally loaded, then changed to 1 and the profile was reloaded,
then the symbolic links would not exist, even though the rawdata does.

Fixes: d61c57fde8191 ("apparmor: make export of raw binary profile to userspace optional")
Signed-off-by: Georgia Garcia 
Signed-off-by: John Johansen

apparmor: make fn_label_build() capable of handling not supported

2026-06-14T03:14:07+00:00

Currently fn_label_build() callback fns must provide a transition or
failure. Change this so that a callback can indicate it should be
skipped/not be involved in the label being built.

This will be useful when building object labels based on mediation
flags, as to whether the label should be set.

Existing callers can keep treating NULL return as an error because
none of those callback fns support skipping, but instead of the old
error handling replace with AA_BUG.

Reviewed-by: Georgia Garcia 
Signed-off-by: John Johansen

apparmor: change fn_label_build() call to not return NULL

2026-06-14T03:14:07+00:00

Previously fn_label_build() was accepting a NULL which represented
ENOMEM return and ERR_PTR for errors.

Clean this up by requiring the cb fn to return an ERR_PTR or valid
value.

Reviewed-by: Georgia Garcia 
Signed-off-by: John Johansen

apparmor: add a conditional version of get_newest_label

2026-06-14T03:14:06+00:00

get_newest_label() will always return a refcount, on the profile it
returns. However there are cases where we only need the refcount
if the label is stale and get_newest_label() will return a different
label.

Optimize this by making the get/put happen conditionally, by keeping
a flag indicating if the get was performed and a put is needed.

Signed-off-by: John Johansen

apparmor: fix race between freeing data and fs accessing it

2026-03-09T23:05:44+00:00

AppArmor was putting the reference to i_private data on its end after
removing the original entry from the file system. However the inode
can aand does live beyond that point and it is possible that some of
the fs call back functions will be invoked after the reference has
been put, which results in a race between freeing the data and
accessing it through the fs.

While the rawdata/loaddata is the most likely candidate to fail the
race, as it has the fewest references. If properly crafted it might be
possible to trigger a race for the other types stored in i_private.

Fix this by moving the put of i_private referenced data to the correct
place which is during inode eviction.

Fixes: c961ee5f21b20 ("apparmor: convert from securityfs to apparmorfs for policy ns files")
Reported-by: Qualys Security Advisory 
Reviewed-by: Georgia Garcia 
Reviewed-by: Maxime Bélair 
Reviewed-by: Cengiz Can 
Signed-off-by: John Johansen

apparmor: fix race on rawdata dereference

2026-03-09T23:05:44+00:00

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 
Reviewed-by: Georgia Garcia 
Reviewed-by: Maxime Bélair 
Reviewed-by: Cengiz Can 
Tested-by: Salvatore Bonaccorso 
Signed-off-by: John Johansen

apparmor: fix differential encoding verification

2026-03-09T23:05:43+00:00

Differential encoding allows loops to be created if it is abused. To
prevent this the unpack should verify that a diff-encode chain
terminates.

Unfortunately the differential encode verification had two bugs.

1. it conflated states that had gone through check and already been
   marked, with states that were currently being checked and marked.
   This means that loops in the current chain being verified are treated
   as a chain that has already been verified.

2. the order bailout on already checked states compared current chain
   check iterators j,k instead of using the outer loop iterator i.
   Meaning a step backwards in states in the current chain verification
   was being mistaken for moving to an already verified state.

Move to a double mark scheme where already verified states get a
different mark, than the current chain being kept. This enables us
to also drop the backwards verification check that was the cause of
the second error as any already verified state is already marked.

Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding")
Reported-by: Qualys Security Advisory 
Tested-by: Salvatore Bonaccorso 
Reviewed-by: Georgia Garcia 
Reviewed-by: Cengiz Can 
Signed-off-by: John Johansen

apparmor: fix unprivileged local user can do privileged policy management

2026-03-09T23:05:43+00:00

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 
Tested-by: Salvatore Bonaccorso 
Reviewed-by: Georgia Garcia 
Reviewed-by: Cengiz Can 
Signed-off-by: John Johansen