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

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

[syzbot]

Hello,

syzbot found the following issue on:

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
Modules linked in:
CPU: 1 UID: 0 PID: 7224 Comm: syz.3.389 Tainted: G             L      syzkaller #0 PREEMPT(full) 
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:remove_proc_entry+0x4f5/0x610 fs/proc/generic.c:747
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 c7 00 00 00 48 8d 3d e9 5f 6c 0e 49 8b 95 d0 00 00 00 48 c7 c6 40 00 ea 8b <67> 48 0f b9 3a e9 2a fe ff ff e8 0c ca 4d ff 48 8d 7d 18 48 b8 00
RSP: 0018:ffffc900054c7780 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: ffff88801c7a2e9c
RDX: ffff88801c3a45dc RSI: ffffffff8bea0040 RDI: ffffffff9128f260
RBP: ffff88801c7a2e78 R08: ffff88803a22821c R09: ffffed10038f45bb
R10: ffff88801c7a2ddb R11: 0000000000000000 R12: ffff88801c7a2dc0
R13: ffff88801c3a4500 R14: ffff88803a2281f8 R15: dffffc0000000000
FS:  00007fc0e43926c0(0000) GS:ffff8880d5ede000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000001000 CR3: 0000000058a9a000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 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
RIP: 0033:0x7fc0e359de99
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc0e4392028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fc0e3825fa0 RCX: 00007fc0e359de99
RDX: 000000000000000c RSI: 0000200000001100 RDI: 0000000000000003
RBP: 00007fc0e3633eaf R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fc0e3826038 R14: 00007fc0e3825fa0 R15: 00007ffe30698be8
 </TASK>
----------------
Code disassembly (best guess):
   0:	00 fc                	add    %bh,%ah
   2:	ff                   	lcall  (bad)
   3:	df 48 89             	fisttps -0x77(%rax)
   6:	fa                   	cli
   7:	48 c1 ea 03          	shr    $0x3,%rdx
   b:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   f:	0f 85 c7 00 00 00    	jne    0xdc
  15:	48 8d 3d e9 5f 6c 0e 	lea    0xe6c5fe9(%rip),%rdi        # 0xe6c6005
  1c:	49 8b 95 d0 00 00 00 	mov    0xd0(%r13),%rdx
  23:	48 c7 c6 40 00 ea 8b 	mov    $0xffffffff8bea0040,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	e9 2a fe ff ff       	jmp    0xfffffe5e
  34:	e8 0c ca 4d ff       	call   0xff4dca45
  39:	48 8d 7d 18          	lea    0x18(%rbp),%rdi
  3d:	48                   	rex.W
  3e:	b8                   	.byte 0xb8


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

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

Thanks,

        tglx

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

[Greg Kroah-Hartman]

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

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

[Ian Abbott]

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 )=-