[syzbot] [pci?] BUG: unable to handle kernel paging request in pci_resource_io

[syzbot] [pci?] BUG: unable to handle kernel paging request in pci_resource_io

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    ba5cc80fd326 Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=10a6afb9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ccf4bea59f67007
dashboard link: https://syzkaller.appspot.com/bug?extid=7134530b25073b4ef373
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16f4a132580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1398efb9580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/959ad5f4e730/disk-ba5cc80f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0787d25f251e/vmlinux-ba5cc80f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2e85c36fabac/Image-ba5cc80f.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7134530b25073b4ef373@syzkaller.appspotmail.com

Unable to handle kernel paging request at virtual address ffffffffc0801001
KASAN: maybe wild-memory-access in range [0
KASAN: maybe wild-memory-access in range [0x0003fffe04008008-0x0003fffe0400800f]
Mem abort info:
  ESR = 0x0000000096000061
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x21: alignment fault
Data abort info:
  ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000
  CM = 0, WnR = 1, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000021b036000
[ffffffffc0801001] pgd=0000000000000000, p4d=0000000221322403, pud=0000000221323403, pmd=1000000102b2a403, pte=00f800003eff1713
Internal error: Oops: 0000000096000061 [#1]  SMP
Modules linked in:
CPU: 1 UID: 0 PID: 4917 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/02/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : __raw_writew arch/arm64/include/asm/io.h:36 [inline]
pc : _outw include/asm-generic/io.h:650 [inline]
pc : logic_outw+0x58/0x124 lib/logic_pio.c:305
lr : _outw include/asm-generic/io.h:649 [inline]
lr : logic_outw+0x48/0x124 lib/logic_pio.c:305
sp : ffff800098937980
x29: ffff800098937980 x28: ffff800098937b88 x27: 1fffe0001a6e7a00
x26: dfff800000000000 x25: 0000000000000100 x24: 0000000000001002
x23: 000000000000101f x22: 0000000000001001 x21: 0000000000ffbfff
x20: 0000000000001001 x19: 0000000000000002 x18: 0000000000000000
x17: ffff800080c9e010 x16: ffff800080c9ded4 x15: 00000000200000c0
x14: ffff800080f03ea0 x13: 0000000000000001 x12: ffff0000c4881d40
x11: 00000000685d429e x10: 000000000000007f x9 : 0000000000000000
x8 : ffffffffc0801001 x7 : ffff800080f080b4 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000002 x3 : ffff800086896aa8
x2 : 0000000000001001 x1 : ffff0000c4881d40 x0 : 0000000000000000
Call trace:
 _outw include/asm-generic/io.h:650 [inline] (P)
 logic_outw+0x58/0x124 lib/logic_pio.c:305 (P)
 pci_resource_io+0x1f4/0x3dc drivers/pci/pci-sysfs.c:1187
 pci_write_resource+0x78/0x90 drivers/pci/pci-sysfs.c:1221
 sysfs_kf_bin_write+0x154/0x194 fs/sysfs/file.c:167
 kernfs_fop_write_iter+0x260/0x3b8 fs/kernfs/file.c:345
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x51c/0xa0c fs/read_write.c:687
 ksys_pwrite64+0x118/0x1ac fs/read_write.c:794
 __do_sys_pwrite64 fs/read_write.c:802 [inline]
 __se_sys_pwrite64 fs/read_write.c:799 [inline]
 __arm64_sys_pwrite64+0xa8/0xc0 fs/read_write.c:799
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
 do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
 el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:738
 el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:757
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:590
Code: 929fffe8 d50332bf f2b81008 8b080288 (79000113) 
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
   0:	929fffe8 	mov	x8, #0xffffffffffff0000    	// #-65536
   4:	d50332bf 	dmb	oshst
   8:	f2b81008 	movk	x8, #0xc080, lsl #16
   c:	8b080288 	add	x8, x20, x8
* 10:	79000113 	strh	w19, [x8] <-- trapping instruction


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

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] [pci?] BUG: unable to handle kernel paging request in pci_resource_io

[Rihyeon Kim]

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

Forwarded: Re: [syzbot] [pci?] BUG: unable to handle kernel paging request in pci_resource_io

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: Re: [syzbot] [pci?] BUG: unable to handle kernel paging request in pci_resource_io
Author: rihyeon8648@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git ba5cc80fd32665ed609037ff30ede8d194f24aab

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 5ec0b24..2aba909 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1175,6 +1175,16 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
 	if (port + count - 1 > pci_resource_end(pdev, bar))
 		return -EINVAL;

+	/*
+	 * Architectures that have no separate I/O address space emulate port
+	 * I/O with an MMIO window at PCI_IOBASE, so @port becomes an address
+	 * in a Device memory mapping.  Unaligned accesses to Device memory
+	 * fault there, and @port is fully controlled by the file offset, so
+	 * require the access to be naturally aligned.
+	 */
+	if (!IS_ALIGNED(port, count))
+		return -EINVAL;
+
 	switch (count) {
 	case 1:
 		if (write)