## Host environment - Operating system: Linux - OS/kernel version: Linux 6.5.0-104-generic - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: git master (commit b833716681, post-v11.0.0) - QEMU command line: qemu-system-x86_64 -M q35 -m 512M -machine cxl=on -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52 -M cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.size=4G -device cxl-rp,bus=cxl.0,id=rp.0,chassis=0,slot=0 -device cxl-type3,bus=rp.0,persistent-memdev=cxl-mem0,lsa=lsa0,id=cxl-pmem0 -object memory-backend-file,id=cxl-mem0,mem-path=/tmp/cxl-mem.dat,size=256M -object memory-backend-file,id=lsa0,mem-path=/tmp/lsa.dat,size=256M -nographic -accel qtest ## Emulated/Virtualized environment - Operating system: Linux - Architecture: x86_64 ## Description of problem I used source code analysis for initial discovery and confirmed the bug with qtest-based reproduction on an unmodified QEMU build. hw/cxl/cxl-device-utils.c:205: mailbox_reg_write() calls g_memdup2(pl, len_in) where pl points to the 2048-byte mailbox payload area (mbox_reg_state + 0x20) and len_in comes from the CXL_DEV_MAILBOX_CMD.LENGTH field (20-bit, max ~1 MB). There is no check that len_in <= CXL_MAILBOX_MAX_PAYLOAD_SIZE (2048). When len_in > 2048, g_memdup2 reads past the payload buffer into adjacent CXLDeviceState heap fields including event_logs[], which contains host heap pointers (QSIMPLEQ_HEAD entries). The over-read data enters pl_in_copy, passed to the command handler. The SET_LSA handler (opcode 0x4103, variable-length in=~0) writes pl_in_copy[8..len_in] into LSA backing memory via set_lsa()->memcpy(). GET_LSA (opcode 0x4102) reads it back to the guest. This creates an info leak: host heap addresses are written to LSA by SET_LSA, then read back by GET_LSA. qtest PoC output (cxl_info_leak_qtest.py, unmodified QEMU): IDENTIFY: errno=0, ret_len=69 (mailbox works) SET_LSA (LENGTH=4096): errno=0 (g_memdup2 reads 4096, 2048 OOB) GET_LSA (offset=2040, length=2048): errno=0, ret_len=2048 Leaked host pointers from CXLDeviceState.event_logs[]: [ 160] 0x00007f801933f6a0 [ 256] 0x00007f801933f700 [ 352] 0x00007f801933f760 [ 448] 0x00007f801933f7c0 [ 544] 0x00007f801933f820 Non-zero bytes: 58/2048 After applying fix: GET_LSA returns 2048 bytes all zero, no host pointers leaked. Fix verified. Repro (qtest, no guest OS needed): 1. Start QEMU with CXL type3 device (command line above) 2. Configure PCI bridges: pxb-cxl (bus 0 dev 3) -> bus 52, cxl-rp (bus 52 dev 0) -> bus 53, cxl-type3 (bus 53 dev 0) 3. Assign BAR2 = 0xfe800000, enable PCI memory space 4. SET_LSA (opcode 0x4103, LENGTH=4096): write payload [offset=0, rsvd=0, 0xAA*2040] ring doorbell -> g_memdup2 reads 4096 bytes (2048 OOB) -> set_lsa writes 4088 bytes to LSA (2040 guest + 2048 OOB) 5. GET_LSA (opcode 0x4102, offset=2040, length=2048): reads back 2048 bytes from LSA containing host heap pointers Impact: confirmed host heap address leak to guest via SET_LSA/GET_LSA echo chain. The leaked addresses (0x7fxxxxxxxxxx range) are QEMU process heap pointers from CXLDeviceState.event_logs[]. This breaks ASLR isolation. Combined with a separate CXL OOB write vulnerability (e.g., missing offset+length validation in SET_FEATURE handler), this enables precise targeting of host heap objects for control flow hijacking. Theoretical: full VM escape requires a separate write primitive; the info leak alone does not grant code execution. Fix: reject commands with len_in > CXL_MAILBOX_MAX_PAYLOAD_SIZE by returning CXL_MBOX_INVALID_PAYLOAD_LENGTH before calling g_memdup2. Patch available, will be sent to qemu-devel after triage. Automated reproducer attached: cxl_info_leak_qtest.py