Disclosure note: This was found during a local QEMU device-audit campaign that used automation, source review, and LLM assistance. I manually triaged the issue and reproduced it with the qtest/runtime evidence below. ## Summary Cadence GEM type1/type2 screening registers expose a 4-bit `QUEUE_NUM` field, but the device RX queue state is stored in fixed arrays sized for `MAX_PRIORITY_QUEUES == 8`. The RX path trusts the screener-selected queue number without clamping it to either `s->num_priority_queues` or `MAX_PRIORITY_QUEUES`. In the validated path, a guest programs a type2 screener ethertype rule with `QUEUE_NUM == 8`, then transmits a normal matching frame through local loopback on `xlnx-zcu102`. `get_queue_from_screen()` returns `8`, and the RX path subsequently indexes `s->rx_desc_addr[8]` and `s->rx_desc[8]`, producing QEMU-process out-of-bounds accesses on fixed queue arrays that have only indices `0..7`. ## Tested version / environment - QEMU source tree: local upstream tree at commit `20553466cc47af6a8c95f665b601fce3c852e503` - QEMU version reported by build: `11.0.50` - Host: x86_64 Linux - Target binary: aarch64-softmmu UBSan/ASan build - Build: aarch64-softmmu with AddressSanitizer and UndefinedBehaviorSanitizer enabled - Machine/device route: `-machine xlnx-zcu102 -qtest unix:...` with GEM0 local loopback ## Affected code - `include/hw/net/cadence_gem.h:40`: `MAX_PRIORITY_QUEUES` is 8. - `include/hw/net/cadence_gem.h:89`: `rx_desc_addr[MAX_PRIORITY_QUEUES]`. - `include/hw/net/cadence_gem.h:96`: `rx_desc[MAX_PRIORITY_QUEUES][DESC_MAX_NUM_WORDS]`. - `hw/net/cadence_gem.c:316`: type1 screener `QUEUE_NUM` is a 4-bit field. - `hw/net/cadence_gem.c:324`: type2 screener `QUEUE_NUM` is a 4-bit field. - `hw/net/cadence_gem.c:884` and `:977`: `get_queue_from_screen()` returns the screener queue field directly. - `hw/net/cadence_gem.c:1022`: `gem_get_desc_addr()` indexes `s->rx_desc_addr[q]`. - `hw/net/cadence_gem.c:1044`: `gem_get_rx_desc()` reads a descriptor into `s->rx_desc[q]`. - `hw/net/cadence_gem.c:1165-1221`: `gem_receive()` repeatedly uses `s->rx_desc[q]` and `s->rx_desc_addr[q]` for RX DMA copy, descriptor writeback, and descriptor advancement. ## Trigger The guest controls Cadence GEM MMIO register writes. In the validated reproducer, the guest writes: - `R_SCREENING_TYPE2_ETHERTYPE_REG0 = 0x88b5` - `R_SCREENING_TYPE2_REG0 = (1 << 12) | 8` That enables a type2 ethertype match and sets `QUEUE_NUM` to `8`. A matching 60-byte Ethernet frame is then transmitted through local loopback after programming one RX descriptor, one TX descriptor, and enabling receive/transmit. ## Security boundary / triggerability This is triggered through guest-programmable Cadence GEM MMIO state and a guest-originated packet on the emulated device path. I am filing confidentially because the guest-controlled screener result reaches host QEMU fixed-array accesses without a queue-index validity check. ## Faulting access The validated runtime evidence shows the unchecked queue selector reaching: - `hw/net/cadence_gem.c:1022`: `s->rx_desc_addr[q]` in `gem_get_desc_addr()` - `hw/net/cadence_gem.c:1218`: `s->rx_desc_addr[q]` during RX descriptor advancement in `gem_receive()` The same queue selector is also used with `s->rx_desc[q]`. ## Reproduction Attached reproducer: `cadence_gem_rx_screener_queue_qtest.py` Run the script against an instrumented aarch64-softmmu binary: ```sh ./cadence_gem_rx_screener_queue_qtest.py --qemu ./build/qemu-system-aarch64 \ > cadence_gem_rx_screener_queue.stdout.txt \ 2> cadence_gem_rx_screener_queue.stderr.txt ``` The script starts QEMU with: ```text qemu-system-aarch64 -machine xlnx-zcu102 -qtest unix:... ``` It programs queue 0 RX/TX descriptors in guest RAM, installs a type2 screener rule for ethertype `0x88b5` with `QUEUE_NUM == 8`, writes a matching 60-byte frame, and enables local loopback with receive/transmit. ## Runtime evidence Attached log: `cadence_gem_rx_screener_queue.stderr.txt` Key runtime evidence: ```text [R +0.037887] writel 0xff0b0540 0x1008 [R +0.038195] writel 0xff0b0000 0x20e ../hw/net/cadence_gem.c:1022:59: runtime error: index 8 out of bounds for type 'uint32_t [8]' ../hw/net/cadence_gem.c:1218:28: runtime error: index 8 out of bounds for type 'uint32_t [8]' ``` The recorded exit status for the validation run was `247` after the instrumented QEMU process reported the bounds violations. ## Triage notes - The reproducer uses a normal 60-byte frame, so the result does not depend on a short-packet condition. - `gem_can_receive()` only checks whether any configured RX queue is ready; it does not validate the screener-selected queue before `gem_receive()` uses it. - RX length checks and RX buffer-size checks constrain packet size and guest-RAM DMA length, not the queue index. - `gem_realize()` validates the configured queue count, but the violating value is the guest-programmed runtime screener field. - The evidence here is from runtime bounds instrumentation at the actual fixed-array index sites, not only from static reasoning. ## Impact A guest with access to the emulated Cadence GEM controller can trigger host QEMU out-of-bounds accesses on fixed RX queue descriptor state by programming a screener rule with `QUEUE_NUM >= 8`. I have not assessed exploitability beyond the confirmed memory-safety violation. ## Suggested fix direction Clamp or reject the screener-selected queue before any RX queue state is indexed. Conservative options include: - require `q < s->num_priority_queues`; - also require `q < MAX_PRIORITY_QUEUES` as a defensive invariant; - drop the packet, route it to queue 0, or raise a guest error according to the intended hardware model; - consider enforcing the same invariant inside `get_queue_from_screen()` so future callers do not inherit the unchecked selector. ## Attachments - [cadence_gem_rx_screener_queue.stderr.txt](/uploads/51c7036f41f07f901422e060513d712b/cadence_gem_rx_screener_queue.stderr.txt) - [cadence_gem_rx_screener_queue_qtest.py](/uploads/4e85bad1a3e0983f5d2ffdf75e422345/cadence_gem_rx_screener_queue_qtest.py)