Re: [syzbot] [pci?] BUG: unable to handle kernel paging request in pci_resource_io
Rihyeon Kim <[email protected]>
| Newsgroups | org.kernel.vger.linux-pci,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Sat Aug 8, 2026 at 8:18 PM UTC, syzbot wrote: > Unable to handle kernel paging request at virtual address ffffffffc0801001 > FSC = 0x21: alignment fault > pc : logic_outw+0x58/0x124 lib/logic_pio.c:305 > pci_resource_io+0x1f4/0x3dc drivers/pci/pci-sysfs.c:1187 I'm interested in this one and had a look at it today. I can reproduce it here, with the same faulting address and the same ESR 0x96000061 as the report. It seems that pci_resource_io() validates the access width (1, 2 or 4 bytes) and the range against the BAR, but never checks that the port itself is naturally aligned. The port is the BAR start plus the sysfs file offset, so a 2-byte write at an odd offset reaches outw() with an odd port number. arm64 has no separate I/O address space, so outw() becomes the __raw_writew() to PCI_IOBASE + port that the report shows in the pc line. The pte in the report has AttrIndx 4, i.e. MT_DEVICE_nGnRE, so that window is Device memory and the unaligned store faults. The registers in the report seem to agree. x22 and x23 are 0x1001 and 0x101f, which is an offset of 1 into a 32-byte I/O BAR at 0x1000, and x21 is 0xffbfff, i.e. MMIO_UPPER_LIMIT, so logic_outw() took the _outw() branch rather than the indirect PIO one. PCI_IOBASE is 0xffffffffc0800000 there, and adding the 0x1001 port gives the faulting address exactly. The read path goes through the same helper, and an unaligned pread() faults the same way in inw(). If anything it is easier to reach, since pci_read_resource() has no security_locked_down() check. If I'm reading this correctly, rejecting accesses whose port is not naturally aligned for the width should be enough, and it would not affect any aligned access that works today. I will prepare a patch. Thanks, Rihyeon Kim