On 02/07/2019 11:31, Paul Durrant wrote: >> -----Original Message----- >> From: Andrew Cooper <andrew.coop...@citrix.com> >> Sent: 02 July 2019 11:29 >> To: Paul Durrant <paul.durr...@citrix.com>; xen-devel@lists.xenproject.org >> Cc: Igor Druzhinin <igor.druzhi...@citrix.com>; Wei Liu <w...@xen.org>; Jan >> Beulich <jbeul...@suse.com>; >> Roger Pau Monne <roger....@citrix.com> >> Subject: Re: [Xen-devel] [PATCH] x86/msi: fix loop termination condition in >> pci_msi_conf_write_intercept() >> >> On 02/07/2019 10:47, Andrew Cooper wrote: >>> On 02/07/2019 10:34, Paul Durrant wrote: >>>> The for loop that deals with MSI masking is coded as follows: >>>> >>>> for ( pos = 0; pos < entry->msi.nvec; ++pos, ++entry ) >>>> >>>> Thus the loop termination condition is dereferencing a struct pointer that >>>> is being incremented by the loop. However, it is clear from following code >>>> paths in msi_capability_init() that this is unsafe as for instance, in the >>>> case of nvec == 1, entry will point at a single struct msi_desc allocation >>>> and thus the loop will walk beyond the bounds of the allocation before >>>> dereferencing the memory to determine whether the loop should terminate. >>> More specifically, only entry[0].msi.nvec is correct. All subsequent >>> nvec fields are 0 in a block of entries. >>> >>>> Also, because the body of the loop writes via the entry pointer, this can >>>> then lead to heap memory corruption, or indeed corruption of anything in >>>> the direct map. >>>> >>>> This patch simply initializes a stack variable to the value of >>>> entry->msi.nvec before starting the loop and then uses that in the >>>> termination condition instead. >> There is actually a second bug here which is being fixed. How about >> this for the commit message? >> > Apart from exchange/outlook terminally mangling it (as you can probably see > below... unless it miraculously unmangles this reply), it looks ok to me. I > assume you are happy to fix on commit?
Yeah - that is horrifically mangled. The actual commit reads sensibly. I'm happy to fix on commit. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
