** Description changed: [Impact] When the audit rate limit is exceeded, memory starts leaking, this can be observed by: watch -d -n 1 grep -i SUnreclaim' /proc/meminfo Unreclaimable slab grows rapidly and lead to run out of all available memory Only reboot can recover it. 5.15 kernel doesn't have this issue, it's introduced later than 5.19 kernel, and caused by LSM stacking code. [Fix] This upstream patch fixes the issue: https://lore.kernel.org/audit/[email protected]/T/#t and merged into maintainer's tree: https://github.com/linux-audit/audit-kernel/commit/d2c773159327f4d2f6438acf1ae2ae9ac0ca46a9 [Test Plan] Add the following line to set a small rate limit in /etc/audit/rules.d/audit.rules: -a always,exit -F arch=b64 -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -r 100 Trigger permission denied by running the following command as a normal user: while :; do cat /proc/1/environ; done Make sure we see the warning message in kernel log: [ 2531.862184] audit: rate limit exceeded [Where problems could occur] Originally the skb is leak and no one is able to process or free it anymore. The above patch just frees the leaking skb when rate limit is exceeded, there won't be any additional impact. + + [ Other Info ] + https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2098730
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2122554 Title: memory leaks when configuring a small rate limit in audit Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Status in linux source package in Plucky: In Progress Status in linux source package in Questing: In Progress Bug description: [Impact] When the audit rate limit is exceeded, memory starts leaking, this can be observed by: watch -d -n 1 grep -i SUnreclaim' /proc/meminfo Unreclaimable slab grows rapidly and lead to run out of all available memory Only reboot can recover it. 5.15 kernel doesn't have this issue, it's introduced later than 5.19 kernel, and caused by LSM stacking code. [Fix] This upstream patch fixes the issue: https://lore.kernel.org/audit/[email protected]/T/#t and merged into maintainer's tree: https://github.com/linux-audit/audit-kernel/commit/d2c773159327f4d2f6438acf1ae2ae9ac0ca46a9 [Test Plan] Add the following line to set a small rate limit in /etc/audit/rules.d/audit.rules: -a always,exit -F arch=b64 -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -r 100 Trigger permission denied by running the following command as a normal user: while :; do cat /proc/1/environ; done Make sure we see the warning message in kernel log: [ 2531.862184] audit: rate limit exceeded [Where problems could occur] Originally the skb is leak and no one is able to process or free it anymore. The above patch just frees the leaking skb when rate limit is exceeded, there won't be any additional impact. [ Other Info ] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2098730 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122554/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
