[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260120000307.369587-1-huzhengmian@gmail.com>
Date: Mon, 19 Jan 2026 19:03:06 -0500
From: Zhengmian Hu <huzhengmian@...il.com>
To: john.johansen@...onical.com,
john@...armor.net,
apparmor@...ts.ubuntu.com
Cc: linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org,
Zhengmian Hu <huzhengmian@...il.com>
Subject: [PATCH v2 0/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer
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
Powered by blists - more mailing lists