On Mon, Sep 26, 2016 at 4:01 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 22/09/2016 19:22, Peter Maydell wrote: >> + case GEM_RECEIVE_Q1_PTR ... GEM_RECEIVE_Q15_PTR: >> + s->rx_desc_addr[offset - GEM_RECEIVE_Q1_PTR + 1] = val; >> + break; > > MAX_PRIORITY_QUEUES is still 8, so this can cause an out-of-bounds write > in s->rx_desc_addr (and likewise for s->tx_addr).
The MAX_PRIORITY_QUEUES is actually right, there are only 8 supported. I guess when this was modeled it was just assumed there would be 16. I checked the spec and confirmed there are only 8, so I have fixed up the logic around that. Thanks, Alistair > > Paolo >
