On Thu, Sep 26, 2024 at 10:58:57AM +0300, Michael Tokarev wrote: > 25.09.2024 13:23, Mattias Nissler wrote: > > On Wed, Sep 25, 2024 at 12:03 PM Michael Tokarev <m...@tls.msk.ru> wrote: > .. > > > So, the issue has now become CVE-2024-8612 (information leak), with this > > > commit (v9.1.0-134-g637b0aa139) being the fix. > > > > Interesting. IIUC, this is triggered by device implementations calling > > dma_memory_unmap with an incorrect size parameter as provided by a > > hostile guest. Shouldn't the device implementations be fixed to > > validate the parameter as well? Maybe this has already happened? It > > would seem the more targeted fix to me. > > Yes, a similar question occurred to me too, - this change does not look > like a proper fix for CVE-2024-8612. And nope, no other changes has been > made to fix it properly, in the device implementations. > > Maybe now with CVE-2024-8612 in place, we can fix the actual problem in > the right place, instead of relying on this change.. > > > > Should we back-port it to previous stable releases of qemu? > > > (it applies to 9.1 but not to 9.0, and I haven't tested it even in 9.1. > > > If anything it needs some work for 9.0 and before) > > > > FWIW, I've been running with earlier variants of this since at least > > 8.0.50, so a backport shouldn't be hard. Note that if we decide to > > backport, we should also include "mac_dbdma: Remove leftover > > `dma_memory_unmap` calls", which fixes a bug uncovered in mac_dbdma > > uncovered by the concurrent bounce buffers change. > > So far I picked this and mac_dbdma change for 9.1, and will try to > back-port things up to 8.2. But it is better - IMHO - to have a real, > more targetting, fix for CVE-2024-8612.
Agree 100% here. Cc a bunch more people involved. > Thanks, > > /mjt
