CVE-2021-47603

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: improve robustness of the audit queue handling<br /> <br /> If the audit daemon were ever to get stuck in a stopped state the<br /> kernel&amp;#39;s kauditd_thread() could get blocked attempting to send audit<br /> records to the userspace audit daemon. With the kernel thread<br /> blocked it is possible that the audit queue could grow unbounded as<br /> certain audit record generating events must be exempt from the queue<br /> limits else the system enter a deadlock state.<br /> <br /> This patch resolves this problem by lowering the kernel thread&amp;#39;s<br /> socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks<br /> the kauditd_send_queue() function to better manage the various audit<br /> queues when connection problems occur between the kernel and the<br /> audit daemon. With this patch, the backlog may temporarily grow<br /> beyond the defined limits when the audit daemon is stopped and the<br /> system is under heavy audit pressure, but kauditd_thread() will<br /> continue to make progress and drain the queues as it would for other<br /> connection problems. For example, with the audit daemon put into a<br /> stopped state and the system configured to audit every syscall it<br /> was still possible to shutdown the system without a kernel panic,<br /> deadlock, etc.; granted, the system was slow to shutdown but that is<br /> to be expected given the extreme pressure of recording every syscall.<br /> <br /> The timeout value of HZ/10 was chosen primarily through<br /> experimentation and this developer&amp;#39;s "gut feeling". There is likely<br /> no one perfect value, but as this scenario is limited in scope (root<br /> privileges would be needed to send SIGSTOP to the audit daemon), it<br /> is likely not worth exposing this as a tunable at present. This can<br /> always be done at a later date if it proves necessary.