Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
Jason Gunthorpe <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Aug 13, 2026 at 05:59:05PM +0100, Robin Murphy wrote: > On 11/08/2026 2:11 pm, Jason Gunthorpe wrote: > > On Tue, Aug 11, 2026 at 01:57:38PM +0100, Robin Murphy wrote: > > > > > But where would that unmap be? > > > > If the theory is right then the bug would be some concurrent driver > > thread like a work queue/timer or a user thread going into a fops that > > outlives the driver remove function. That thread would do the unmap. > > > > This is an extremely common bug class in drivers at least.. > > > > eg DRM has lots of challenges in this area if the guess about VGA is > > correct. > > Oh, indeed - I futzed with it a little bit and sure enough: > > [ 225.056075][ T1] [drm] Found bochs VGA, ID 0xb0c5. > [ 225.071671][ T1] [drm] Framebuffer size 16384 kB @ 0xfd000000, mmio @ 0xfebd4000. > [ 226.061260][ T1] [drm] Initialized bochs-drm 1.0.0 for 0000:00:01.0 on minor 2 > [ 229.801060][ T1] bochs-drm 0000:00:01.0: [drm] fb1: bochs-drmdrmfb frame buffer device wow nice job to find that! > It's a well known thing that DRM drivers can't really support device > removal or any kind of forced driver unbinding at all, as the drm_device > can be held open by users and outlive its underlying driver, then it's > UAF city in more ways than anyone cares to enumerate. Furthermore, a > completely bogus dma_unmap() of the VGA framebuffer's physical address > in a misguided attempt to clean up a doomed unbind might well explain a > reserved IOVA getting freed as well... > > So yeah, move along folks, nothing to see here :) I was told DRM has mitigations now, but they have to be deployed in drivers. So this would be a bochs driver bug I suppose? Jason