aboutsummaryrefslogtreecommitdiff
path: root/rust/qemu-api/src
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2025-02-28 17:48:00 +0000
committerPhilippe Mathieu-Daudé <philmd@linaro.org>2025-03-11 20:02:48 +0100
commitaad6f264add3f2be72acb660816588fe09110069 (patch)
treeb641e2038332815335bd65e424bf8e772fc1610c /rust/qemu-api/src
parent2fa3a5b9469615d06091cf473d172794148e1248 (diff)
downloadqemu-aad6f264add3f2be72acb660816588fe09110069.zip
qemu-aad6f264add3f2be72acb660816588fe09110069.tar.gz
qemu-aad6f264add3f2be72acb660816588fe09110069.tar.bz2
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte which is at the end of the data area and CRC. However, we don't sanitize the length field in the packet buffer, so if the guest sets the length field to something large we will try to read past the end of the packet data buffer when we access the control byte. As usual, the datasheet says nothing about the behaviour of the hardware if the guest misprograms it in this way. It says only that the maximum valid length is 2048 bytes. We choose to log the guest error and silently drop the packet. This requires us to factor out the "mark the tx packet as complete" logic, so we can call it for this "drop packet" case as well as at the end of the loop when we send a valid packet. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250228174802.1945417-3-peter.maydell@linaro.org> [PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Diffstat (limited to 'rust/qemu-api/src')
0 files changed, 0 insertions, 0 deletions