audit: fix skb leak when audit rate limit is exceeded

When configuring a small audit 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

And then repeatedly triggering permission denied as a normal user:
while :; do cat /proc/1/environ; done

We can see the messages in kernel log:
  [ 2531.862184] audit: rate limit exceeded

The unreclaimable slab objects start to leak quickly. With kmemleak
enabled, many call traces appear like:
unreferenced object 0xffff99144b13f600 (size 232):
  comm "cat", pid 1100, jiffies 4294739144
  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 (crc 8540ec4f):
    kmemleak_alloc+0x4a/0x90
    kmem_cache_alloc_node+0x2ea/0x390
    __alloc_skb+0x174/0x1b0
    audit_log_start+0x198/0x3d0
    audit_log_proctitle+0x32/0x160
    audit_log_exit+0x6c6/0x780
    __audit_syscall_exit+0xee/0x140
    syscall_exit_work+0x12b/0x150
    syscall_exit_to_user_mode_prepare+0x39/0x80
    syscall_exit_to_user_mode+0x11/0x260
    do_syscall_64+0x8c/0x180
    entry_SYSCALL_64_after_hwframe+0x78/0x80

This shows that the skb allocated in audit_log_start() and queued
onto skb_list is never freed.

In audit_log_end(), each skb is dequeued from skb_list and passed
to __audit_log_end(). However, when the audit rate limit is exceeded,
__audit_log_end() simply prints "rate limit exceeded" and returns
without processing the skb. Since the skb is already removed from
skb_list, audit_buffer_free() cannot free it later, leading to a
memory leak.

Fix this by freeing the skb when the rate limit is exceeded.

Fixes: eb59d494eebd ("audit: add record for multiple task security contexts")
Signed-off-by: Gerald Yang <gerald.yang@canonical.com>
[PM: fixes tag, subj tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>

0 files changed, 0 insertions, 0 deletions