On Thu, 10 Sept 2026 at 15:55, Marc-André Lureau <[email protected]> wrote: > > Hi > > On Thu, Sep 10, 2026 at 6:45 PM Peter Maydell <[email protected]> > wrote: > > > > On Thu, 10 Sept 2026 at 14:30, Marc-André Lureau > > <[email protected]> wrote: > > > > > > The following changes since commit > > > 257bf4f160c50ca8c4ebd603f519f5c786013fb7: > > > > > > Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into > > > staging (2026-09-10 11:08:04 +0100) > > > > > > are available in the Git repository at: > > > > > > https://gitlab.com/marcandre.lureau/qemu.git tags/virtio-gpu-pr-v1 > > > > > > for you to fetch changes up to d26343c12d84227263b8d2fc89bac7632a98e00d: > > > > > > contrib/vhost-user-gpu: disable scanouts on resource unref (2026-09-10 > > > 17:29:47 +0400) > > > > > > ---------------------------------------------------------------- > > > Various virtio-gpu/dmabuf related fixes > > > > > > Hi, > > > > > > While working on CVE-2026-66020 (which had a few revision on list), I > > > kept finding several places where virtio-gpu scanout and dmabuf > > > ownership was unclear. > > > > > > The CVE comes from using a blob after RESOURCE_DETACH_BACKING has > > > unmapped its memory. Following that path also found stale dmabuf > > > references, duplicated scanout bookkeeping, and inconsistent cleanup > > > between display backends. > > > > > > Those changes touch a lot of area and I have done basic testing with the > > > various backends. I would not recommend backporting them all to stable. > > > The first 2 patches address CVE-2026-66020 in the general case and > > > should be safe to backport. > > > > > > thanks > > > > > > To: [email protected] > > > Cc: Alex Bennée <[email protected]> > > > Cc: Akihiko Odaki <[email protected]> > > > Cc: Dmitry Osipenko <[email protected]> > > > Cc: "Michael S. Tsirkin" <[email protected]> > > > Cc: Stefano Garzarella <[email protected]> > > > Cc: Alex Williamson <[email protected]> > > > Cc: Cédric Le Goater <[email protected]> > > > Signed-off-by: Marc-André Lureau <[email protected]> > > > > > > --- > > > Changes in v5: > > > - EDITME: describe what is new in this series revision. > > > - EDITME: use bulletpoints and terse descriptions. > > > - Link to v4: > > > https://lore.kernel.org/qemu-devel/[email protected] > > > > So is this different from the v4 on list? Please don't send pull > > requests as if they were new revisions of individual patch series. > > This is not the mechanism the project uses: pull requests should > > be an accumulation of whatever patches the maintainer of a > > subsystem has. Sometimes that will happen to be a single > > patchset, but usually not. > > My bad, I should have cleaned-up the series cover letter. There is no > difference with v4 beside trailer tags. > I didn't include other pending ui or related patches, I could, but I > would rather have smaller PR.
Thanks for clarifying. > I can send another PR if those extra lines in the cover letter are too > dirty. Let me know I think since the text is also in the commit message for the merge commit and so it all appears in the git log it would be worth cleaning that up and sending a fresh PR. (You can just resend a new cover letter email with the new pullreq info, you don't need to resend all the patchmails.) thanks -- PMM
