The libvirt RPC handler for `virNodeGetFreePages` sizes its return buffer as `pages.pages_len * cellCount`, where both are attacker-controlled 32-bit wire fields. `pages_len` is XDR-capped at `REMOTE_NODE_MAX_CELLS` (1024), but `cellCount` is an unbounded `unsigned int`. The product is computed in 32-bit arithmetic and wraps modulo 2^32 before it is compared against `REMOTE_NODE_MAX_CELLS`, so a large `cellCount` makes the guard see a tiny value and pass; `g_new0` then allocates that same wrapped (tiny) element count, while the driver goes on to write `numNUMAnodes * pages_len` `uint64` entries into it. The result is a heap buffer overflow in the daemon's address space. The handler is annotated `@acl connect:read`, the lowest read permission, and the read-only Unix socket ships world-accessible (mode 0666), so any unprivileged local user reaches it without authentication. Because the daemon runs as root in the default system configuration, this is an unprivileged-local to root-daemon heap corruption: a reliable denial of service and a plausible local privilege-escalation primitive. ## Root cause The dispatcher computes the guard and the allocation from the same 32-bit product: https://gitlab.com/libvirt/libvirt/-/blob/69335a484768d550854da1133d5490074695e825/src/remote/remote_daemon_dispatch.c#L6755-6763 ```c if (args->pages.pages_len * args->cellCount > REMOTE_NODE_MAX_CELLS) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("the result won't fit into REMOTE_NODE_MAX_CELLS")); goto cleanup; } /* Allocate return buffer. */ ret->counts.counts_val = g_new0(uint64_t, args->pages.pages_len * args->cellCount); ``` `pages_len` is bounded by XDR but `cellCount` is not: https://gitlab.com/libvirt/libvirt/-/blob/69335a484768d550854da1133d5490074695e825/src/remote/remote_protocol.x#L3448-3450 ```c unsigned int pages<REMOTE_NODE_MAX_CELLS>; int startCell; unsigned int cellCount; ``` Both operands are `unsigned int` (32-bit), so `pages_len * cellCount` truncates modulo 2^32. With `pages_len = 1023` and `cellCount = 4198405`, the true product is `4294968315`, which wraps to `1019`, comfortably below 1024, so the guard passes and `g_new0` allocates only 1019 `uint64` (8152 bytes). `g_new0`'s own `n * sizeof` overflow check is defeated because it is handed the already-wrapped element count. The write side then iterates the host's real NUMA cells and writes `pages_len` counts per cell: https://gitlab.com/libvirt/libvirt/-/blob/69335a484768d550854da1133d5490074695e825/src/util/virhostmem.c#L863-874 ```c lastCell = MIN(lastCell, startCell + (int) cellCount - 1); for (cell = startCell; cell <= lastCell; cell++) { for (i = 0; i < npages; i++) { unsigned int page_size = pages[i]; unsigned long long page_free; if (virNumaGetPageInfo(cell, page_size, 0, NULL, &page_free) < 0) return -1; counts[ncounts++] = page_free; } } ``` So the buffer holds the wrapped count while the write extent is `numNUMAnodes * pages_len` entries, overflowing the allocation on any host with at least one NUMA node (kilobytes past the end). The written values are per-page free counts, so the content is only partially attacker-controlled, which favours a reliable crash and heap-grooming corruption over straightforward code execution. The handler's ACL is the lowest read tier (`@acl: connect:read`, remote_protocol.x:4124), and the read-only socket units ship at mode 0666 for both the monolithic (`libvirtd-ro.socket`) and modular (`virtd-ro.socket`, e.g. virtqemud) daemons, so a `VIR_CONNECT_RO` client with no polkit authentication reaches this path. The serving daemon is root in system mode. No CVE covers this. ## Proof of Concept The overflowing write is performed by real libvirt code, so the PoC drives it. Inside the Docker build it clones and pins libvirt to `69335a484768d550854da1133d5490074695e825`, asserts `HEAD` equals the pin, and builds libvirt with AddressSanitizer (the always-present test driver plus the public API). The harness reproduces the dispatcher's allocation arithmetic verbatim (the two lines above), then calls the real public API `virNodeGetFreePages`, which dispatches into the real shipped `testNodeGetFreePages` driver and performs the overflowing write into the under-allocated buffer. The attack uses wrapping `pages_len`/`cellCount`; the control uses small non-wrapping values. [poc.zip](/uploads/794f1d9a5659de99c8ab015c20d965b7/poc.zip) ``` docker build -t poc . && docker run --rm poc ``` ### Result ``` checked-out HEAD: 69335a484768d550854da1133d5490074695e825 expected pin : 69335a484768d550854da1133d5490074695e825 PIN OK === the 32-bit product is tested, then reused for g_new0 (remote_daemon_dispatch.c) === if (args->pages.pages_len * args->cellCount > REMOTE_NODE_MAX_CELLS) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("the result won't fit into REMOTE_NODE_MAX_CELLS")); goto cleanup; } /* Allocate return buffer. */ ret->counts.counts_val = g_new0(uint64_t, args->pages.pages_len * args->cellCount); cellCount is an unbounded wire field (remote_protocol.x): 3450: unsigned int cellCount; 3448: unsigned int pages<REMOTE_NODE_MAX_CELLS>; === control: pages_len*cellCount does NOT wrap -> buffer fits -> no overflow === [*] mode=control pages_len=2 cellCount=2 : 32-bit product = 4 (<= 1024, guard passes) [*] mode=control virNodeGetFreePages returned 4 (no overflow detected) control exit=0 === attack: pages_len*cellCount wraps mod 2^32 past the guard -> undersized buffer === [*] mode=attack pages_len=1023 cellCount=4198405 : 32-bit product = 1019 (<= 1024, guard passes) ==15==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5250000048d8 at pc 0x7f21d61223a2 bp 0x7ffcb55a3360 sp 0x7ffcb55a3350 WRITE of size 8 at 0x5250000048d8 thread T0 #0 0x7f21d61223a1 in testNodeGetFreePages ../src/test/test_driver.c:4541 0x5250000048d8 is located 0 bytes after 8152-byte region [0x525000002900,0x5250000048d8) SUMMARY: AddressSanitizer: heap-buffer-overflow ../src/test/test_driver.c:4541 in testNodeGetFreePages attack exit=134 ``` The control's `pages_len * cellCount` (4) does not wrap, the buffer fits the write, and `virNodeGetFreePages` returns cleanly. The attack's product wraps to 1019, so `g_new0` allocates an 8152-byte buffer while the driver writes past it: AddressSanitizer reports a `heap-buffer-overflow WRITE` 0 bytes after the 8152-byte region. In the real daemon the same wrapped allocation is written by `virHostMemGetFreePages` for every NUMA cell of the host, so a `virNodeGetFreePages` RPC with a crafted `pages_len`/`cellCount` from an unprivileged client on the read-only socket corrupts the root daemon's heap. (The PoC's `testNodeGetFreePages` write is the shipped test-driver stand-in for that production write; both overflow the same under-allocated buffer.) ## Mitigation Validate `cellCount` (and the product) before allocating: bound `cellCount` in `remote_protocol.x` the same way `pages` is bounded, and compute the guard and allocation in 64-bit (e.g. compare `(size_t)pages_len * cellCount` against `REMOTE_NODE_MAX_CELLS` before the multiply can truncate), rejecting the request if it exceeds the limit. Both the guard and the `g_new0` size must use the untruncated product. ## Attribution This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged manually with manual report writing by Ada Logics in collaboration with Anthropic Research.