BUG: error receiving audit netlink packet (No buffer space available)

[sulphur]

Hi,

Issue Description

I am encountering an issue with the Auditd service on my system, which is consistently generating the error message Error receiving audit netlink packet (No buffer space available). This error appears to be related to a buffer space limitation when receiving audit netlink packets.

Environment

• Operating System: Ubuntu 20.04
• Auditd Package Version: auditd/focal,now 1:2.8.5-2ubuntu6 amd64

Custom Audit Rules

I should also note that I have custom audit rules added by F-Secure antivirus, which may be relevant to this issue because they can generate a lot of events. Here are the custom audit rules that are loaded:

auditctl -l
-a always,exit -F arch=b64 -S clone,fork,vfork,execve -F key=atp_process
-a always,exit -F arch=b32 -S fork,execve,clone,vfork -F key=atp_process
-a always,exit -F arch=b64 -S init_module -F key=atp_syscall
-a always,exit -F arch=b32 -S init_module -F key=atp_syscall
-a always,exit -F arch=b64 -S delete_module -F key=atp_syscall
-a always,exit -F arch=b32 -S delete_module -F key=atp_syscall
-a always,exit -F arch=b64 -S chdir -F key=atp_syscall
-a always,exit -F arch=b32 -S chdir -F key=atp_syscall
-a always,exit -F arch=b64 -S finit_module -F key=atp_syscall
-a always,exit -F arch=b32 -S finit_module -F key=atp_syscall
-a always,exit -F arch=b64 -S ptrace -F a0!=0x4204 -F a0!=0x18 -F key=atp_syscall
-a always,exit -F arch=b32 -S ptrace -F a0!=0x4204 -F a0!=0x18 -F key=atp_syscall
-a always,exit -F arch=b64 -S connect,accept,bind,listen,accept4 -F key=atp_socket
-a always,exit -F arch=b32 -S socketcall -F a0=0x2 -F key=atp_socket
-a always,exit -F arch=b32 -S socketcall -F a0=0x3 -F key=atp_socket
-a always,exit -F arch=b32 -S socketcall -F a0=0x4 -F key=atp_socket
-a always,exit -F arch=b32 -S socketcall -F a0=0x5 -F key=atp_socket
-a always,exit -F arch=b32 -S socketcall -F a0=0x12 -F key=atp_socket

Audispd Configuration

I have attempted to increase the q_depth in audispd to 65536 and also increased -b to 65536 in /etc/audit/audit.rules in an attempt to address this issue. However, the error persists.

cat /etc/audit/auditd.conf
#
# Ansible managed
#
# Generated by Ansible role devsec.hardening.os_hardening

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 76
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
max_log_file = 50
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
tcp_listen_queue = 5
tcp_max_per_addr = 1
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd

and audidspd conf :

cat /etc/audisp/audispd.conf
#
# This file controls the configuration of the audit event
# dispatcher daemon, audispd.
#

# commented by F-Secure:q_depth = 250
overflow_action = SYSLOG
# commented by F-Secure:priority_boost = 4
max_restarts = 10
name_format = HOSTNAME
#name = mydomain
plugin_dir = /etc/audisp/plugins.d/
# commented by F-Secure
#q_depth = 16384
# commented by F-Secure
#priority_boost = 10

q_depth = 32768
priority_boost = 20

Steps Taken

I have attempted to troubleshoot the issue by checking disk space, adjusting auditd configuration settings, and investigating any potential conflicts with other services or configurations. However, I have not been able to resolve the problem.

Expected Behavior

The Auditd service should operate without generating the "Error receiving audit netlink packet (No buffer space available)" error.

Thank you for your help in addressing this problem.

[pcmoore]

Hi @sulphur,

The error message you are seeing indicates that the audit userspace is receiving a ENOBUFS error code from the kernel when trying to receive a reply over the audit netlink socket. Unfortunately the ENOBUFS error code is not used in the audit subsystem itself, but rather by the underlying netlink transport mechanism. Have you noticed any other problems on the system? Is the system under a particularly heavy load?

Looking quickly it appears that Ubuntu 20.04 may be running either a v5.4 or v5.15 kernel, depending on kernel variant installed. Sadly, both of these kernels are quite old, four and two years respectively. Are you able to reproduce these problems on a modern upstream kernel?

You may also try contacting the audit-userspace folks to see if they have any suggestions on tuning the kernel and/or audit daemon to help mitigate this problem.

[sulphur]

Hi @pcmoore,

Thank you for your response. The system isn't under heavy load; actually, it's not under any load at all since it's in the pre-production stage. The only issue is with the antivirus software, which adds its rules to the audit, causing auditd to generate 1GB of logs per day 😅. So, I'm confident this is related to the antivirus because we didn't have these errors before. That's why I'm looking into how to tune auditd so that it functions correctly, as this antivirus relies on audit logs to list files for "on-access scans."

Unfortunately, I can't provide information on newer kernels since the company has locked us into using Ubuntu 20.04 with the 5.4 kernel.

I will follow your suggestion and also seek help in the userspace.

[pcmoore]

Thanks for the background information, I'll leave this issue open for now but please report back and let us know how things went - good luck!