Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova

[Robin Murphy <robin.murphy@arm.com>]

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.