* Re: [syzbot] [kernel?] WARNING: proc registration bug in unregister_irq_proc (2)
2026-07-27 14:22 ` [syzbot] [kernel?] WARNING: proc registration bug in unregister_irq_proc (2) Thomas Gleixner
@ 2026-07-27 14:33 ` Greg Kroah-Hartman
2026-07-28 19:09 ` Thomas Gleixner
2026-07-27 15:03 ` Ian Abbott
1 sibling, 1 reply; 4+ messages in thread
From: Greg Kroah-Hartman @ 2026-07-27 14:33 UTC (permalink / raw)
To: Thomas Gleixner
Cc: syzbot, linux-kernel, syzkaller-bugs, Danilo Krummrich,
Rafael J. Wysocki, driver-core, Bjorn Helgaas, linux-pci,
Ian Abbott
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [kernel?] WARNING: proc registration bug in unregister_irq_proc (2)
2026-07-27 14:22 ` [syzbot] [kernel?] WARNING: proc registration bug in unregister_irq_proc (2) Thomas Gleixner
2026-07-27 14:33 ` Greg Kroah-Hartman
@ 2026-07-27 15:03 ` Ian Abbott
1 sibling, 0 replies; 4+ messages in thread
From: Ian Abbott @ 2026-07-27 15:03 UTC (permalink / raw)
To: Thomas Gleixner, syzbot, linux-kernel, syzkaller-bugs
Cc: Greg Kroah-Hartman, Danilo Krummrich, Rafael J. Wysocki,
driver-core, Bjorn Helgaas, linux-pci
On 2026-07-27 15:22, 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().
Yes, the device's I/O base address and IRQ number are configured by an
ioctl() for this driver. (The process doing that needs CAP_SYS_ADMIN
capability. There is also precedent for this sort of thing in the
TIOCSSERIAL ioctl() command for configuring TTY serial ports since the
early days of the Linux kernel.)
Back in the old days of PCs with ISA buses, you could configure the BIOS
to reserve specified IRQs so that they would not be assigned to PCI
devices, so you could use them for ISA devices.
>
> Though deciphering this comedi code is beyond my skillset.
>
> I rather go and harden the interrupt core against such bogosities.
>
> Thanks,
>
> tglx
>
>
>
--
-=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
^ permalink raw reply [flat|nested] 4+ messages in thread