Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers

[Li Qiang]

Jason Wang <jasowang@redhat.com> 于2020年7月21日周二 下午9:21写道：
>
>
> On 2020/7/21 下午8:31, Peter Maydell wrote:
> > On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasowang@redhat.com> wrote:
> >> I think the point is to make DMA to MMIO work as real hardware.
> > I wouldn't care to give a 100% guarantee that asking a real
> > h/w device to DMA to itself didn't cause it to misbehave :-)
> > It's more likely to happen-to-work because the DMA engine bit
> > of a real h/w device is going to be decoupled somewhat from
> > the respond-to-memory-transactions-for-registers logic, but
> > it probably wasn't something the designers were actively
> > thinking about either...
>
>
> I think some device want such peer to peer transactions:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst
>
>
> >
> >> For
> >> e1000e and other networking devices we need make sure such DMA doesn't
> >> break anything.
> > Yeah, this is the interesting part for QEMU. How should we
> > structure devices that do DMA so that we can be sure that
> > the device emulation at least doesn't crash? We could have
> > a rule that all devices that do DMA must always postpone
> > all of that DMA to a bottom-half, but that's a lot of
> > refactoring of a lot of device code...
>
>
> It looks to me the issue happens only for device with loopback

IMO I think this is not related-loopback.

It happens when the guest write the MMIO address to the device's
DMA-related registers.
The one we see UAF occurs in loopback device because the same
structure uses in re-entry.
But we can't say there are no issue for non-loopback device.

>
> Simply git grep loopback in hw/net tells me we probably need only to
> audit dp8393x and rtl8139.
>
> Qiang, want to help to audit those devices?

No problem. Once I finish the e1000e patch I will try to audit those and
also try to audit some no-loopback device re-entry issue.

Thanks,
Li Qiang

>
> Thanks
>
>
> >
> > thanks
> > -- PMM
> >
>