Preface: Log management allows you to monitor requests at any level (API, database, etc.) and see which are underperforming. Log management is based on log files.
Log files are important data points for security and surveillance, providing a full history of events over time. Beyond operating systems, log files are found in applications, web browsers, hardware, and even email.

Background: It is important to control the sizes of log files on a Linux server because their size always grows over time. Every server has limited resources and too large logs can lead to performance and memory problems, not to mention the loss of precious storage space. This problem is typically solved through log rotation, a process that involves renaming or compressing a log file before it gets too large, and cleaning up old logs to reclaim storage.

Vulnerability details: A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation.

Remedy for older releases of logrotate (from 3.17.0 to 3.19.0):

https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9
https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d

Besides users can upgrade to 3.20.1 – https://github.com/logrotate/logrotate/releases/tag/3.20.1

My comment: From security point of view, it is a critical risk. For example, SIEM relies log event to do the correlation function. If such vulnerability happen and log event agent do not have reporting mechanism to confirm the log events activities. It such a way provide a channel to attacker to try the evade activities because alert function will not respond by firing rule.