[PATCH v2 0/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer

[PATCH v2 0/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer

[Zhengmian Hu]

Hi all,

This series fixes a per-cpu hold counter underflow in the AppArmor buffer
cache. Under high-frequency execve workloads with AppArmor enabled, cache->hold
can wrap to UINT_MAX, preventing buffers from returning to the global list and
forcing repeated kmalloc(aa_g_path_max) allocations.

Summary:
On high-frequency execve workloads with AppArmor enabled, the per-CPU buffer
cache can enter a pathological state: aa_get_buffer() decrements hold even
when it is already zero, causing an unsigned underflow. The resulting huge
hold value prevents aa_put_buffer() from refilling the global list, which
starves other CPUs and forces repeated kmalloc(aa_g_path_max) allocations.
Because the AppArmor pool does not shrink, this accumulates into large
kmalloc-8k slab growth over time.

Repro (QEMU TCG, 4 vCPU, 1 GiB RAM, v6.16):
- Unpatched: kmalloc-8k objects grow 12->16 in 120s (run1), 16->20 in 120s (run2)
- Patched: kmalloc-8k stays at 12 for 120s

Notes:
This fix targets the observed underflow mechanism without changing the overall
AppArmor buffer pool design. Happy to provide the reproduction script and logs
on request.

Changes in v2:
- Add patch description to the commit message.

Thanks,
Zhengmian Hu

Zhengmian Hu (1):
  apparmor: avoid per-cpu hold underflow in aa_get_buffer

 security/apparmor/lsm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.52.0

[PATCH v2 1/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer

[Zhengmian Hu]

When aa_get_buffer() pulls from the per-cpu list it unconditionally
decrements cache->hold. If hold reaches 0 while count is still non-zero,
the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a
very long time, so aa_put_buffer() never returns buffers to the global
list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max)
allocations.

Guard the decrement so hold never underflows.

Signed-off-by: Zhengmian Hu <huzhengmian@gmail.com>
---
 security/apparmor/lsm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 9b6c2f157..a6c884ba6 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1868,7 +1868,8 @@ char *aa_get_buffer(bool in_atomic)
 	if (!list_empty(&cache->head)) {
 		aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
 		list_del(&aa_buf->list);
-		cache->hold--;
+		if (cache->hold)
+			cache->hold--;
 		cache->count--;
 		put_cpu_ptr(&aa_local_buffers);
 		return &aa_buf->buffer[0];
-- 
2.52.0

Re: [PATCH v2 1/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer

[John Johansen]

On 1/19/26 16:03, Zhengmian Hu wrote:
> When aa_get_buffer() pulls from the per-cpu list it unconditionally
> decrements cache->hold. If hold reaches 0 while count is still non-zero,
> the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a
> very long time, so aa_put_buffer() never returns buffers to the global
> list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max)
> allocations.
> 
> Guard the decrement so hold never underflows.
> 
> Signed-off-by: Zhengmian Hu <huzhengmian@gmail.com>

thanks, Acked-by: John Johansen <john.johansen@canonical.com>

I have pulled this into apparmor-next

> ---
>   security/apparmor/lsm.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 9b6c2f157..a6c884ba6 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1868,7 +1868,8 @@ char *aa_get_buffer(bool in_atomic)
>   	if (!list_empty(&cache->head)) {
>   		aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
>   		list_del(&aa_buf->list);
> -		cache->hold--;
> +		if (cache->hold)
> +			cache->hold--;
>   		cache->count--;
>   		put_cpu_ptr(&aa_local_buffers);
>   		return &aa_buf->buffer[0];