Re: [syzbot] [kernel?] WARNING: proc registration bug in unregister_irq_proc (2)

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Mon, Jul 27, 2026 at 04:22:58PM +0200, Thomas Gleixner wrote:
> On Sat, Jul 25 2026 at 15:42, syzbot wrote:
> 
> > HEAD commit:    3dab139d4795 Merge tag 'rust-fixes-7.2-2' of git://git.ker..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=156bd88e580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=145fa60d73086782
> > dashboard link: https://syzkaller.appspot.com/bug?extid=690d666eb12fca6e1e61
> > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > 
> > Unfortunately, I don't have any reproducer for this issue yet.
> > 
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-3dab139d.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/2b5a401a9dc7/vmlinux-3dab139d.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/7ed2d255bd44/bzImage-3dab139d.xz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+690d666eb12fca6e1e61@syzkaller.appspotmail.com
> 
> > ------------[ cut here ]------------
> > remove_proc_entry: removing non-empty directory 'irq/20', leaking at least 'comedi_parport'
> > WARNING: fs/proc/generic.c:747 at remove_proc_entry+0x4e7/0x610 fs/proc/generic.c:747, CPU#1: syz.3.389/7224
> 
> So this frees an interupt descriptor, which still has an active
> interrupt request on it.
> 
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 7224 Comm: syz.3.389 Tainted: G             L      syzkaller #0 PREEMPT(full) 
> >  unregister_irq_proc+0x206/0x2a0 kernel/irq/proc.c:406
> >  free_desc+0x89/0x330 kernel/irq/irqdesc.c:482
> >  irq_free_descs kernel/irq/irqdesc.c:874 [inline]
> >  irq_free_descs+0x84/0xc0 kernel/irq/irqdesc.c:865
> >  irq_domain_free_irqs+0x46a/0x5c0 kernel/irq/irqdomain.c:1917
> >  mp_unmap_irq+0xf8/0x130 arch/x86/kernel/apic/io_apic.c:1061
> >  acpi_unregister_gsi_ioapic+0x40/0x60 arch/x86/kernel/acpi/boot.c:722
> >  acpi_unregister_gsi+0x25/0x40 arch/x86/kernel/acpi/boot.c:751
> >  acpi_pci_irq_disable+0x275/0x360 drivers/acpi/pci_irq.c:517
> >  pcibios_disable_device arch/x86/pci/common.c:706 [inline]
> >  pcibios_disable_device+0x89/0xb0 arch/x86/pci/common.c:703
> >  do_pci_disable_device+0x9f/0x100 drivers/pci/pci.c:2170
> >  pci_disable_device+0x130/0x270 drivers/pci/pci.c:2206
> >  pci_device_remove+0xb2/0x1d0 drivers/pci/pci-driver.c:512
> >  device_remove+0xcb/0x180 drivers/base/dd.c:616
> >  __device_release_driver drivers/base/dd.c:1349 [inline]
> >  device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1372
> >  unbind_store+0xf8/0x110 drivers/base/bus.c:244
> >  drv_attr_store+0x74/0xb0 drivers/base/bus.c:125
> >  sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
> >  kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
> >  new_sync_write fs/read_write.c:595 [inline]
> >  vfs_write+0x6ac/0x1050 fs/read_write.c:687
> >  ksys_write+0x12a/0x250 fs/read_write.c:739
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> unbind() releases the driver, which removes the device, but the device
> removal does not end up freeing the requested interrupt and
> pci_device_remove() ends up correctly freeing the legacy PCI interrupt
> descriptor through the above call chain.
> 
> The real question is how that comedi parport driver ends up on a PCI
> device without actually registering a PCI driver with a proper remove
> callback. It seems it just attaches blindly to something which user
> space hands in through the ioctl().
> 
> Though deciphering this comedi code is beyond my skillset.
> 
> I rather go and harden the interrupt core against such bogosities.

Sure, but really, anyone doing a manual "unbind" gets to keep the pieces
if the kernel can't handle it. The comedi driver really aren't all that
ready for stuff like this as they are in systems that are fixed to the
shop floor, driving big stone cutters.

So no real rush/need that I can see here.

thanks,

greg k-h