[BUG] thunderbolt: page fault on ioread32 in nhi_probe

[BUG] thunderbolt: page fault on ioread32 in nhi_probe

[CJ]

Hi,


I am reporting a page fault in the Thunderbolt NHI probe path, triggered by a
syzkaller reproducer.  The issue is reproducible with HEAD commit
cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).


The reproducer mounts sysfs, unbinds PCI device 0000:00:03.0, writes
"thunderbolt" to its driver_override attribute, and then writes the device name
to the thunderbolt driver's bind attribute, forcing the driver onto a device
that is not a Thunderbolt controller.


The console shows "BUG: unable to handle page fault for address:
00000000000556c0" with a supervisor read access, RIP in ioread32 (readl
inlined), reached from nhi_probe and nhi_pci_probe through local_pci_probe.  The
faulting address is a low MMIO-style address, which indicates a register access
at an offset from a base that was never mapped for this device.


One possible cause is that nhi_probe issues MMIO reads at register offsets
without first confirming that the device's BAR was assigned, so a forced bind on
an unrelated PCI device makes it read an unmapped address.  The fault address in
the original report differs only in its low byte from the one seen here, which I
take as resource-placement drift rather than a different access.  This looks
like a missing resource-validity check on the probe path.  I note that recent
work in this file (9cbc63400f7d, f1de1fc5f632) touched probe-time
initialization but not this path.


This appears to be a recurrence of the syzbot issue whose external id is
6f1d620d17b844ec2cf7.  It remains reproducible on v7.3-rc1.


Reproducer:


syz reproducer:
mkdirat(0xffffffffffffff9c, &(0x7f0000000040)='./sys\x00', 0x1ff)
mount(0x0, &(0x7f0000000080)='./sys\x00', &(0x7f00000000c0)='sysfs\x00', 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000100)='./sys/bus/pci/devices/0000:00:03.0/driver/unbind\x00', 0x1, 0x0)
write(r0, &(0x7f0000000140)='0000:00:03.0\x00', 0xd)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000180)='./sys/bus/pci/devices/0000:00:03.0/driver_override\x00', 0x1, 0x0)
write(r1, &(0x7f00000001c0)='thunderbolt\x00', 0xc)
r2 = openat(0xffffffffffffff9c, &(0x7f0000000200)='./sys/bus/pci/drivers/thunderbolt/bind\x00', 0x1, 0x0)
write(r2, &(0x7f0000000240)='0000:00:03.0\x00', 0xd)


console output: https://pastebin.com/raw/KTfCvNLB
kernel config: https://pastebin.com/raw/uuDqY6v9


Kernel:


HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
           e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)


Let me know if you need more details or testing.


Best regards,
Changjian

Re: [BUG] thunderbolt: page fault on ioread32 in nhi_probe

[Mika Westerberg]

Hi,

On Mon, Sep 14, 2026 at 05:02:42PM +0800, CJ wrote:
> 
> Hi,
> 
> 
> I am reporting a page fault in the Thunderbolt NHI probe path, triggered by a
> syzkaller reproducer.  The issue is reproducible with HEAD commit
> cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).
> 
> 
> The reproducer mounts sysfs, unbinds PCI device 0000:00:03.0, writes
> "thunderbolt" to its driver_override attribute, and then writes the device name
> to the thunderbolt driver's bind attribute, forcing the driver onto a device
> that is not a Thunderbolt controller.
> 
> 
> The console shows "BUG: unable to handle page fault for address:
> 00000000000556c0" with a supervisor read access, RIP in ioread32 (readl
> inlined), reached from nhi_probe and nhi_pci_probe through local_pci_probe.  The
> faulting address is a low MMIO-style address, which indicates a register access
> at an offset from a base that was never mapped for this device.

Yes if you bind it to a random device you get what you asked for. Don't do
that. I think syzkaller recently got fixed not to do that.