Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
Robin Murphy <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 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 :) Thanks, Robin.