qemu/qemu.git, branch stable-7.2

Update version for 7.2.22 release

2025-12-05T07:23:51+00:00

Signed-off-by: Michael Tokarev

hw/misc/npcm_clk: Don't divide by zero when calculating frequency

2025-11-14T21:32:43+00:00

If the guest misprograms the PLL registers to request a zero divisor, we currently fall over with a division by zero: ../../hw/misc/npcm_clk.c:221:14: runtime error: division by zero SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../hw/misc/npcm_clk.c:221:14 Thread 1 "qemu-system-aar" received signal SIGFPE, Arithmetic exception. 0x00005555584d8f6d in npcm7xx_clk_update_pll (opaque=0x7fffed159a20) at ../../hw/misc/npcm_clk.c:221 221 freq /= PLLCON_INDV(con) * PLLCON_OTDV1(con) * PLLCON_OTDV2(con); Avoid this by treating this invalid setting like a stopped clock (setting freq to 0). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/549 Signed-off-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé Message-id: 20251107150137.1353532-1-peter.maydell@linaro.org (cherry picked from commit 5fc50b4ec841c8a01e7346c2c804088fc3accb6b) Signed-off-by: Michael Tokarev

hw/display/xlnx_dp: Don't abort for unsupported graphics formats

2025-11-14T21:32:43+00:00

If the guest writes an invalid or unsupported value to the AV_BUF_FORMAT register, currently we abort(). Instead, log this as either a guest error or an unimplemented error and continue. The existing code treats DP_NL_VID_CB_Y0_CR_Y1 as x8b8g8r8 via a "case 0" that does not use the enum constant name for some reason; we leave that alone beyond adding a comment about the weird code. Documentation of this register seems to be at: https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/AV_BUF_FORMAT-DISPLAY_PORT-Register Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1415 Signed-off-by: Peter Maydell Reviewed-by: Edgar E. Iglesias Reviewed-by: Philippe Mathieu-Daudé Message-id: 20251106145209.1083998-3-peter.maydell@linaro.org (cherry picked from commit 032333eba77b83dfbd74071cc2971f0bda9a3d4f) Signed-off-by: Michael Tokarev

hw/display/xlnx_dp.c: Don't abort on AUX FIFO overrun/underrun

2025-11-14T21:32:43+00:00

The documentation of the Xilinx DisplayPort subsystem at https://www.xilinx.com/support/documents/ip_documentation/v_dp_txss1/v3_1/pg299-v-dp-txss1.pdf doesn't say what happens if a guest tries to issue an AUX write command with a length greater than the amount of data in the AUX write FIFO, or tries to write more data to the write FIFO than it can hold, or issues multiple commands that put data into the AUX read FIFO without reading it such that it overflows. Currently QEMU will abort() in these guest-error situations, either in xlnx_dp.c itself or in the fifo8 code. Make these cases all be logged as guest errors instead. We choose to ignore the new data on overflow, and return 0 on underflow. This is in line with how we handled the "read from empty RX FIFO" case in commit a09ef5040477. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1418 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1419 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1424 Signed-off-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Edgar E. Iglesias Message-id: 20251106145209.1083998-2-peter.maydell@linaro.org (cherry picked from commit f52db7f34242d3398bab0bacaa3e5dde99be5258) Signed-off-by: Michael Tokarev

net: pad packets to minimum length in qemu_receive_packet()

2025-11-14T21:32:43+00:00

In commits like 969e50b61a28 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") we switched away from requiring network devices to handle short frames to instead having the net core code do the padding of short frames out to the ETH_ZLEN minimum size. We then dropped the code for handling short frames from the network devices in a series of commits like 140eae9c8f7 ("hw/net: e1000: Remove the logic of padding short frames in the receive path"). This missed one route where the device's receive code can still see a short frame: if the device is in loopback mode and it transmits a short frame via the qemu_receive_packet() function, this will be fed back into its own receive code without being padded. Add the padding logic to qemu_receive_packet(). This fixes a buffer overrun which can be triggered in the e1000_receive_iov() logic via the loopback code path. Other devices that use qemu_receive_packet() to implement loopback are cadence_gem, dp8393x, lan9118, msf2-emac, pcnet, rtl8139 and sungem. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3043 Reviewed-by: Akihiko Odaki Signed-off-by: Peter Maydell Signed-off-by: Jason Wang (cherry picked from commit a01344d9d78089e9e585faaeb19afccff2050abf) Signed-off-by: Michael Tokarev

hw/net/e1000e_core: Adjust e1000e_write_payload_frag_to_rx_buffers() assert

2025-11-14T21:32:43+00:00

An assertion in e1000e_write_payload_frag_to_rx_buffers() attempts to guard against the calling code accidentally trying to write too much data to a single RX descriptor, such that the E1000EBAState::cur_idx indexes off the end of the EB1000BAState::written[] array. Unfortunately it is overzealous: it asserts that cur_idx is in range after it has been incremented. This will fire incorrectly for the case where the guest configures four buffers and exactly enough bytes are written to fill all four of them. The only places where we use cur_idx and index in to the written[] array are the functions e1000e_write_hdr_frag_to_rx_buffers() and e1000e_write_payload_frag_to_rx_buffers(), so we can rewrite this to assert before doing the array dereference, rather than asserting after updating cur_idx. Cc: qemu-stable@nongnu.org Reviewed-by: Akihiko Odaki Signed-off-by: Peter Maydell Signed-off-by: Jason Wang (cherry picked from commit bab496a18358643b686f69e2b97d73fb98d37e79) (Mjt: in 7.2.x it is e1000e_write_to_rx_buffers, not e1000e_write_payload_frag_to_rx_buffers, due to missing in 7.2.x v8.1.0-693-g17ccd0164796 "igb: RX payload guest writting refactoring") Signed-off-by: Michael Tokarev

hw/net/e1000e_core: Correct rx oversize packet checks

2025-11-14T21:32:43+00:00

In e1000e_write_packet_to_guest() we attempt to ensure that we don't write more of a packet to a descriptor than will fit in the guest configured receive buffers. However, this code does not allow for the "packet split" feature. When packet splitting is enabled, the first of up to 4 buffers in the descriptor is used for the packet header only, with the payload going into buffers 2, 3 and 4. Our length check only checks against the total sizes of all 4 buffers, which meant that if an incoming packet was large enough to fit in (1 + 2 + 3 + 4) but not into (2 + 3 + 4) and packet splitting was enabled, we would run into the assertion in e1000e_write_hdr_frag_to_rx_buffers() that we had enough buffers for the data: qemu-system-i386: ../../hw/net/e1000e_core.c:1418: void e1000e_write_payload_frag_to_rx_buffers(E1000ECore *, hwaddr *, E1000EBAState *, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS' failed. A malicious guest could provoke this assertion by configuring the device into loopback mode, and then sending itself a suitably sized packet into a suitably arrange rx descriptor. The code also fails to deal with the possibility that the descriptor buffers are sized such that the trailing checksum word does not fit into the last descriptor which has actual data, which might also trigger this assertion. Rework the length handling to use two variables: * desc_size is the total amount of data DMA'd to the guest for the descriptor being processed in this iteration of the loop * rx_desc_buf_size is the total amount of space left in it As we copy data to the guest (packet header, payload, checksum), update these two variables. (Previously we attempted to calculate desc_size once at the top of the loop, but this is too difficult to do correctly.) Then we can use the variables to ensure that we clamp the amount of copied payload data to the remaining space in the descriptor's buffers, even if we've used one of the buffers up in the packet-split code, and we can tell whether we have enough space for the full checksum word in this descriptor or whether we're going to need to split that to the following descriptor. I have included comments that hopefully help to make the loop logic a little clearer. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/537 Reviewed-by: Akihiko Odaki Signed-off-by: Peter Maydell Signed-off-by: Jason Wang (cherry picked from commit 9d946d56a2ac8a6c2df186e20d24810255c83a3f) (Mjt: rename e1000e_write_payload_frag_to_rx_buffers back to e1000e_write_to_rx_buffers for 7.2.x, to compensate for missing in 7.2.x v8.1.0-693-g17ccd0164796 "igb: RX payload guest writting refactoring") Signed-off-by: Michael Tokarev

hw/net/e1000e_core: Don't advance desc_offset for NULL buffer RX descriptors

2025-11-14T21:32:43+00:00

In e1000e_write_packet_to_guest() we don't write data for RX descriptors where the buffer address is NULL (as required by the i82574 datasheet section 7.1.7.2). However, when we do this we still update desc_offset by the amount of data we would have written to the RX descriptor if it had a valid buffer pointer, resulting in our dropping that data entirely. The data sheet is not 100% clear on the subject, but this seems unlikely to be the correct behaviour. Rearrange the null-descriptor logic so that we don't treat these do-nothing descriptors as if we'd really written the data. This both fixes a bug and also is a prerequisite to cleaning up the size calculation logic in the next patch. (Cc to stable largely because it will be needed for the next patch, which fixes a more serious bug.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell Reviewed-by: Akihiko Odaki Signed-off-by: Jason Wang (cherry picked from commit 6da0c9828194eb21e54fe4264cd29a1b85a29f33) (Mjt: context fixup in hw/net/e1000e_core.c:e1000e_write_packet_to_guest()) Signed-off-by: Michael Tokarev

qio: Protect NetListener callback with mutex

2025-11-14T21:32:43+00:00

Without a mutex, NetListener can run into this data race between a thread changing the async callback callback function to use when a client connects, and the thread servicing polling of the listening sockets: Thread 1: qio_net_listener_set_client_func(lstnr, f1, ...); => foreach sock: socket => object_ref(lstnr) => sock_src = qio_channel_socket_add_watch_source(sock, ...., lstnr, object_unref); Thread 2: poll() => event POLLIN on socket => ref(GSourceCallback) => if (lstnr->io_func) // while lstnr->io_func is f1 ...interrupt.. Thread 1: qio_net_listener_set_client_func(lstnr, f2, ...); => foreach sock: socket => g_source_unref(sock_src) => foreach sock: socket => object_ref(lstnr) => sock_src = qio_channel_socket_add_watch_source(sock, ...., lstnr, object_unref); Thread 2: => call lstnr->io_func(lstnr->io_data) // now sees f2 => return dispatch(sock) => unref(GSourceCallback) => destroy-notify => object_unref Found by inspection; I did not spend the time trying to add sleeps or execute under gdb to try and actually trigger the race in practice. This is a SEGFAULT waiting to happen if f2 can become NULL because thread 1 deregisters the user's callback while thread 2 is trying to service the callback. Other messes are also theoretically possible, such as running callback f1 with an opaque pointer that should only be passed to f2 (if the client code were to use more than just a binary choice between a single async function or NULL). Mitigating factor: if the code that modifies the QIONetListener can only be reached by the same thread that is executing the polling and async callbacks, then we are not in a two-thread race documented above (even though poll can see two clients trying to connect in the same window of time, any changes made to the listener by the first async callback will be completed before the thread moves on to the second client). However, QEMU is complex enough that this is hard to generically analyze. If QMP commands (like nbd-server-stop) are run in the main loop and the listener uses the main loop, things should be okay. But when a client uses an alternative GMainContext, or if servicing a QMP command hands off to a coroutine to avoid blocking, I am unable to state with certainty whether a given net listener can be modified by a thread different from the polling thread running callbacks. At any rate, it is worth having the API be robust. To ensure that modifying a NetListener can be safely done from any thread, add a mutex that guarantees atomicity to all members of a listener object related to callbacks. This problem has been present since QIONetListener was introduced. Note that this does NOT prevent the case of a second round of the user's old async callback being invoked with the old opaque data, even when the user has already tried to change the async callback during the first async callback; it is only about ensuring that there is no sharding (the eventual io_func(io_data) call that does get made will correspond to a particular combination that the user had requested at some point in time, and not be sharded to a combination that never existed in practice). In other words, this patch maintains the status quo that a user's async callback function already needs to be robust to parallel clients landing in the same window of poll servicing, even when only one client is desired, if that particular listener can be amended in a thread other than the one doing the polling. CC: qemu-stable@nongnu.org Fixes: 53047392 ("io: introduce a network socket listener API", v2.12.0) Signed-off-by: Eric Blake Message-ID: <20251113011625.878876-20-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé [eblake: minor commit message wording improvements] Signed-off-by: Eric Blake (cherry picked from commit 9d86181874ab7b0e95ae988f6f80715943c618c6) Signed-off-by: Michael Tokarev

qio: Remember context of qio_net_listener_set_client_func_full

2025-11-14T21:32:43+00:00

io/net-listener.c has two modes of use: asynchronous (the user calls qio_net_listener_set_client_func to wake up the callback via the global GMainContext, or qio_net_listener_set_client_func_full to wake up the callback via the caller's own alternative GMainContext), and synchronous (the user calls qio_net_listener_wait_client which creates its own GMainContext and waits for the first client connection before returning, with no need for a user's callback). But commit 938c8b79 has a latent logic flaw: when qio_net_listener_wait_client finishes on its temporary context, it reverts all of the siocs back to the global GMainContext rather than the potentially non-NULL context they might have been originally registered with. Similarly, if the user creates a net-listener, adds initial addresses, registers an async callback with a non-default context (which ties to all siocs for the initial addresses), then adds more addresses with qio_net_listener_add, the siocs for later addresses are blindly placed in the global context, rather than sharing the context of the earlier ones. In practice, I don't think this has caused issues. As pointed out by the original commit, all async callers prior to that commit were already okay with the NULL default context; and the typical usage pattern is to first add ALL the addresses the listener will pay attention to before ever setting the async callback. Likewise, if a file uses only qio_net_listener_set_client_func instead of qio_net_listener_set_client_func_full, then it is never using a custom context, so later assignments of async callbacks will still be to the same global context as earlier ones. Meanwhile, any callers that want to do the sync operation to grab the first client are unlikely to register an async callback; altogether bypassing the question of whether later assignments of a GSource are being tied to a different context over time. I do note that chardev/char-socket.c is the only file that calls both qio_net_listener_wait_client (sync for a single client in tcp_chr_accept_server_sync), and qio_net_listener_set_client_func_full (several places, all with chr->gcontext, but sometimes with a NULL callback function during teardown). But as far as I can tell, the two uses are mutually exclusive, based on the is_waitconnect parameter to qmp_chardev_open_socket_server. That said, it is more robust to remember when an async callback function is tied to a non-default context, and have both the sync wait and any late address additions honor that same context. That way, the code will be robust even if a later user performs a sync wait for a specific client in the middle of servicing a longer-lived QIONetListener that has an async callback for all other clients. CC: qemu-stable@nongnu.org Fixes: 938c8b79 ("qio: store gsources for net listeners", v2.12.0) Signed-off-by: Eric Blake Reviewed-by: Daniel P. Berrangé Message-ID: <20251113011625.878876-19-eblake@redhat.com> (cherry picked from commit b5676493a08b4ff80680aae7a1b1bfef8797c6e7) Signed-off-by: Michael Tokarev