CVE-2023-52501

In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Do not attempt to read past commit

When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. Theres barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left.

The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, theres a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page.

To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d
• https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a
• https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca
• https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49
• https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3
• https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d
• https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a
• https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca
• https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49
• https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3