CVE-2026-54522

This vulnerability in msgpack-ruby's Buffer implementation is not a typical memory management bug — it is a semantic failure where the `clear` method does not do what its name implies. Understanding why requires examining how msgpack's buffer layer actually works. The library maintains a shared pool of memory pages (called rmem) for performance. When you call `Buffer#clear`, the method releases the buffer's working page back to this shared pool — but critically, it does not null out three retained pointers: `rmem_last`, `rmem_end`, and `rmem_owner`. The buffer object remains alive with these stale pointers still attached to its internal state. From the caller's perspective, the buffer appears cleared. Physically, the buffer still holds dereferenceable pointers to memory that now belongs to the shared pool. The exploit window opens immediately after `clear` returns. Any subsequent write operation on the same buffer will dereference these stale pointers — but between the clear and that next write, another Buffer instance can be allocated and claim the identical physical memory from the pool. This creates cross-buffer information disclosure: data you believed was cleared can be read by another buffer's subsequent operations. The aliasing is not a race between threads — it is a race between sequential operations within the same object's lifecycle. What makes this particularly dangerous is that standard memory safety tools will not detect it. ASAN and UBSAN look for classic use-after-free where memory is returned to the system allocator. Here, the memory is returned to an in-process pool and immediately reallocated to a valid owner. The pointers are technically valid — they just point to the wrong buffer's data from a semantic standpoint. This is a "semantic use-after-free" that evades conventional detection. The CVSS 5.4 score understates the real-world risk because msgpack sits in serialization pipelines that carry authenticated data, inter-service credentials, and trust relationships. The disclosure is not random heap noise — it is potentially structured secrets that were placed into msgpack precisely because msgpack is the trusted serialization vehicle. In high-throughput serialization code, buffers are reused aggressively, meaning the aliasing window between `clear` and the next `write` is encountered routinely through normal code flow, not through contrived timing attacks. If you are running msgpack-ruby, ensure you are on version 1.8.2 or later. Review code paths that call `clear` followed by write operations — these are the exact sequences that trigger the aliasing window. Consider whether your application processes sensitive data through msgpack serialization that could be at risk if the aliasing window is exploited during normal request handling.

Reviewed through automated stages and approved by a human before publication.