https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 09:30:18 +0000 https://cve.radiocsirt.org/vuln/brew-portable-ruby-cve-2026-54522 <p><strong>Affected:</strong> Homebrew: portable-ruby</p> <p>### Summary `MessagePack::Buffer#clear` shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer&#39;s rmem cursor (`rmem_last`, `rmem_end`, `rmem_owner`). The next write sees &#34;unused rmem space&#34; left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second `MessagePack::Buffer` then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer&#39;s bytes — a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).</p> <p>### Details - `msgpack_buffer_clear()` → `_msgpack_buffer_shift_chunk()` (`ext/msgpack/buffer.c:151`, `:128`) destroys chunks (`_msgpack_buffer_chunk_destroy`, `:58`, returns the page via `msgpack_rmem_free`) but resets only `tail_buffer_end`/`read_buffer`, leaving `rmem_last`/`rmem_end`/`rmem_owner` pointing into the freed page. - Next `Buffer#write` → `_msgpack_buffer_chunk_malloc()` reuse branch (`:363`) returns `b-&gt;rmem_last`, a pointer into the already-freed page. - A second buffer&#39;s first write calls `msgpack_rmem_alloc()` and gets the same physical page back from the pool → the two buffers alias the same memory. - Sanitizer note: rmem (`ext/msgpack/rmem.h`) recycles pages with a slab bitmask, not `free()`, so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.</p> <p>### PoC Single self-contained script (builds msgpack from rubygems with AddressSanitiz…</p> <p><strong>Affected:</strong> Homebrew: portable-ruby</p> <p>### Summary `MessagePack::Buffer#clear` shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer&#39;s rmem cursor (`rmem_last`, `rmem_end`, `rmem_owner`). The next write sees &#34;unused rmem space&#34; left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second `MessagePack::Buffer` then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer&#39;s bytes — a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).</p> <p>### Details - `msgpack_buffer_clear()` → `_msgpack_buffer_shift_chunk()` (`ext/msgpack/buffer.c:151`, `:128`) destroys chunks (`_msgpack_buffer_chunk_destroy`, `:58`, returns the page via `msgpack_rmem_free`) but resets only `tail_buffer_end`/`read_buffer`, leaving `rmem_last`/`rmem_end`/`rmem_owner` pointing into the freed page. - Next `Buffer#write` → `_msgpack_buffer_chunk_malloc()` reuse branch (`:363`) returns `b-&gt;rmem_last`, a pointer into the already-freed page. - A second buffer&#39;s first write calls `msgpack_rmem_alloc()` and gets the same physical page back from the pool → the two buffers alias the same memory. - Sanitizer note: rmem (`ext/msgpack/rmem.h`) recycles pages with a slab bitmask, not `free()`, so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.</p> <p>### PoC Single self-contained script (builds msgpack from rubygems with AddressSanitiz…</p> https://cve.radiocsirt.org/vuln/brew-portable-ruby-cve-2026-54522 https://cve.radiocsirt.org/vuln/cleanstart-2026-de16221 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ruby-fluentd-1.18</p> <p>Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ruby-fluentd-1.18</p> <p>Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-de16221 https://cve.radiocsirt.org/vuln/euvd-2026-342861 EUVD-2026-342861 https://cve.radiocsirt.org/vuln/euvd-2026-342861 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54522 <p>MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.2, MessagePack::Buffer#clear in ext/msgpack/buffer.c leaves rmem_last, rmem_end, and rmem_owner stale after _msgpack_buffer_shift_chunk returns an rmem page to the shared pool, allowing a subsequent Buffer#write and a second MessagePack::Buffer to alias the page and disclose or corrupt cross-buffer data. This issue is fixed in version 1.8.2.</p> <p>MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.2, MessagePack::Buffer#clear in ext/msgpack/buffer.c leaves rmem_last, rmem_end, and rmem_owner stale after _msgpack_buffer_shift_chunk returns an rmem page to the shared pool, allowing a subsequent Buffer#write and a second MessagePack::Buffer to alias the page and disclose or corrupt cross-buffer data. This issue is fixed in version 1.8.2.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54522 https://cve.radiocsirt.org/vuln/ghsa-4mrv-5p47-p938 <p><strong>Affected:</strong> RubyGems: msgpack</p> <p>### Summary `MessagePack::Buffer#clear` shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer&#39;s rmem cursor (`rmem_last`, `rmem_end`, `rmem_owner`). The next write sees &#34;unused rmem space&#34; left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second `MessagePack::Buffer` then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer&#39;s bytes — a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).</p> <p>### Details - `msgpack_buffer_clear()` → `_msgpack_buffer_shift_chunk()` (`ext/msgpack/buffer.c:151`, `:128`) destroys chunks (`_msgpack_buffer_chunk_destroy`, `:58`, returns the page via `msgpack_rmem_free`) but resets only `tail_buffer_end`/`read_buffer`, leaving `rmem_last`/`rmem_end`/`rmem_owner` pointing into the freed page. - Next `Buffer#write` → `_msgpack_buffer_chunk_malloc()` reuse branch (`:363`) returns `b-&gt;rmem_last`, a pointer into the already-freed page. - A second buffer&#39;s first write calls `msgpack_rmem_alloc()` and gets the same physical page back from the pool → the two buffers alias the same memory. - Sanitizer note: rmem (`ext/msgpack/rmem.h`) recycles pages with a slab bitmask, not `free()`, so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.</p> <p>### PoC Single self-contained script (builds msgpack from rubygems with AddressSanitiz…</p> <p><strong>Affected:</strong> RubyGems: msgpack</p> <p>### Summary `MessagePack::Buffer#clear` shifts out every chunk and returns its 4 KiB rmem page to the shared pool, but does not reset the buffer&#39;s rmem cursor (`rmem_last`, `rmem_end`, `rmem_owner`). The next write sees &#34;unused rmem space&#34; left over from the freed page and hands back a slice of memory that has already been returned to the pool. A second `MessagePack::Buffer` then re-acquires that same page, so reading the cleared-and-rewritten buffer discloses the second buffer&#39;s bytes — a same-process use-after-free with cross-buffer information disclosure (and the symmetric write-corruption).</p> <p>### Details - `msgpack_buffer_clear()` → `_msgpack_buffer_shift_chunk()` (`ext/msgpack/buffer.c:151`, `:128`) destroys chunks (`_msgpack_buffer_chunk_destroy`, `:58`, returns the page via `msgpack_rmem_free`) but resets only `tail_buffer_end`/`read_buffer`, leaving `rmem_last`/`rmem_end`/`rmem_owner` pointing into the freed page. - Next `Buffer#write` → `_msgpack_buffer_chunk_malloc()` reuse branch (`:363`) returns `b-&gt;rmem_last`, a pointer into the already-freed page. - A second buffer&#39;s first write calls `msgpack_rmem_alloc()` and gets the same physical page back from the pool → the two buffers alias the same memory. - Sanitizer note: rmem (`ext/msgpack/rmem.h`) recycles pages with a slab bitmask, not `free()`, so a stock ASAN build does not abort; the cross-buffer disclosure below is the proof.</p> <p>### PoC Single self-contained script (builds msgpack from rubygems with AddressSanitiz…</p> https://cve.radiocsirt.org/vuln/ghsa-4mrv-5p47-p938 https://cve.radiocsirt.org/vuln/msrc_cve-2026-54522 msrc_CVE-2026-54522 https://cve.radiocsirt.org/vuln/msrc_cve-2026-54522 https://cve.radiocsirt.org/vuln/oesa-2026-3219 <p><strong>Affected:</strong> openEuler:24.03-LTS-SP4: rubygem-msgpack</p> <p>MessagePack is a binary-based efficient object serialization library. It enables to exchange structured objects between many languages like JSON. But unlike JSON, it is very fast and small. Security Fix(es):</p> <p>Affected versions of this package are vulnerable to Use After Free in the `clear` function. An attacker can access or manipulate memory contents from another buffer by triggering the reuse of a memory page after it has been returned to the shared pool, leading to unintended disclosure or modification of data.(CVE-2026-54522)</p> <p><strong>Affected:</strong> openEuler:24.03-LTS-SP4: rubygem-msgpack</p> <p>MessagePack is a binary-based efficient object serialization library. It enables to exchange structured objects between many languages like JSON. But unlike JSON, it is very fast and small. Security Fix(es):</p> <p>Affected versions of this package are vulnerable to Use After Free in the `clear` function. An attacker can access or manipulate memory contents from another buffer by triggering the reuse of a memory page after it has been returned to the shared pool, leading to unintended disclosure or modification of data.(CVE-2026-54522)</p> https://cve.radiocsirt.org/vuln/oesa-2026-3219 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54522 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-msgpack, Ubuntu:18.04:LTS: ruby-msgpack, Ubuntu:20.04:LTS: ruby-msgpack, Ubuntu:22.04:LTS: ruby-msgpack, Ubuntu:24.04:LTS: ruby-msgpack, Ubuntu:26.04:LTS: ruby-msgpack</p> <p>MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.2, MessagePack::Buffer#clear in ext/msgpack/buffer.c leaves rmem_last, rmem_end, and rmem_owner stale after _msgpack_buffer_shift_chunk returns an rmem page to the shared pool, allowing a subsequent Buffer#write and a second MessagePack::Buffer to alias the page and disclose or corrupt cross-buffer data. This issue is fixed in version 1.8.2.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-msgpack, Ubuntu:18.04:LTS: ruby-msgpack, Ubuntu:20.04:LTS: ruby-msgpack, Ubuntu:22.04:LTS: ruby-msgpack, Ubuntu:24.04:LTS: ruby-msgpack, Ubuntu:26.04:LTS: ruby-msgpack</p> <p>MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.2, MessagePack::Buffer#clear in ext/msgpack/buffer.c leaves rmem_last, rmem_end, and rmem_owner stale after _msgpack_buffer_shift_chunk returns an rmem page to the shared pool, allowing a subsequent Buffer#write and a second MessagePack::Buffer to alias the page and disclose or corrupt cross-buffer data. This issue is fixed in version 1.8.2.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54522