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

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

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

[Thomas Gleixner]

On Mon, Jul 27 2026 at 16:33, Greg Kroah-Hartman wrote:
> On Mon, Jul 27, 2026 at 04:22:58PM +0200, Thomas Gleixner wrote:
>> 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.

I understand, but it bothers me that the leakage is detected way too
late and only unearthed by removing a proc entry. There might be actual
references dangling. The interrupt core code knows all that at the point
where the teardown starts and that's where it can cleanup the mess and
emit a warning message.

Thanks,

        tglx

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=17569625580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
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
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=157ce979580000

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/17', leaking at least 'comedi_parport'
WARNING: fs/proc/generic.c:747 at remove_proc_entry+0x4e7/0x610 fs/proc/generic.c:747, CPU#0: syz-executor143/6008
Modules linked in:
CPU: 0 UID: 0 PID: 6008 Comm: syz-executor143 Not tainted syzkaller #0 PREEMPT(full) 
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 39 b7 88 0e 49 8b 95 d0 00 00 00 48 c7 c6 80 39 0b 8c <67> 48 0f b9 3a e9 2a fe ff ff e8 4c 2b 4a ff 48 8d 7d 18 48 b8 00
RSP: 0018:ffffc900032af7b8 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: ffff88803dac74dc
RDX: ffff88801cb025dc RSI: ffffffff8c0b3980 RDI: ffffffff91498da0
RBP: ffff88803dac74b8 R08: ffff88802b20f75c R09: ffffed1007b58e83
R10: ffff88803dac741b R11: 0000000000000000 R12: ffff88803dac7400
R13: ffff88801cb02500 R14: ffff88802b20f738 R15: dffffc0000000000
FS:  000055558ac37400(0000) GS:ffff8880d5ba2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007efe6b5a6130 CR3: 000000002bb43000 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:1919
 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:2192
 pci_disable_device+0x130/0x270 drivers/pci/pci.c:2228
 enable_store+0x219/0x260 drivers/pci/pci-sysfs.c:342
 dev_attr_store+0x58/0x80 drivers/base/core.c:2509
 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+0x6af/0x1050 fs/read_write.c:687
 ksys_write+0x12a/0x250 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8d19fda9f7
Code: 48 89 fa 4c 89 df e8 98 1d 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007ffff688d7b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000055558ac37400 RCX: 00007f8d19fda9f7
RDX: 0000000000000002 RSI: 00007f8d1a0120f4 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007f8d1a012129
R13: 00007f8d1a014458 R14: 00007f8d1a0120f4 R15: 0000000000000015
 </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 39 b7 88 0e 	lea    0xe88b739(%rip),%rdi        # 0xe88b755
  1c:	49 8b 95 d0 00 00 00 	mov    0xd0(%r13),%rdx
  23:	48 c7 c6 80 39 0b 8c 	mov    $0xffffffff8c0b3980,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	e9 2a fe ff ff       	jmp    0xfffffe5e
  34:	e8 4c 2b 4a ff       	call   0xff4a2b85
  39:	48 8d 7d 18          	lea    0x18(%rbp),%rdi
  3d:	48                   	rex.W
  3e:	b8                   	.byte 0xb8


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.