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

[Thomas Gleixner]

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@xxxxxxxxxxxxxxxxxxxxxxxxx

> ------------[ 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.

Thanks,

        tglx