On Thu, 26 Feb 2026 at 21:49, Philippe Mathieu-Daudé <[email protected]> wrote:
>
> On 26/2/26 18:55, Peter Maydell wrote:
> > The smc91c111 data frame format in memory (figure 8-1 in the
> > datasheet) includes a "byte count" field which is intended to be the
> > total size of the data frame, including not just the packet data but
> > also the leading and trailing information like the status word and
> > the byte count field itself.  It is therefore possible for the guest
> > to set this to a value so small that the leading and trailing fields
> > won't fit and the packet has effectively a negative area.
> >
> > We weren't checking for this, with the result that when we subtract 6
> > from the length to get the length of the packet proper we end up with
> > a negative length, which is then inconsistently handled in the
> > qemu_send_packet() code such that we can try to transmit a very large
> > amount of data and read off the end of the device's data array.
> >
> > Treat excessively small length values the same way we do excessively
> > large values.  As with the oversized case, the datasheet does not
> > describe what happens for this software error case, and there is no
> > relevant tx error condition for this, so we just log and drop the
> > packet.
> >
> > Cc: [email protected]
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3304
> > Signed-off-by: Peter Maydell <[email protected]>
> > ---
> >   hw/net/smc91c111.c | 16 ++++++++++++++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
>
> Reviewed-by: Philippe Mathieu-Daudé <[email protected]>



Applied to target-arm.next, thanks.

-- PMM

Reply via email to