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

[Jason Gunthorpe <jgg@ziepe.ca>]

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