Re: [PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses
Rihyeon Kim <[email protected]>
| Newsgroups | org.kernel.vger.linux-pci,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Sun Aug 9, 2026 at 4:59 AM UTC, Deepanshu Kartikey wrote: > + if (!IS_ALIGNED(port, count)) > + return -EINVAL; You beat me to it :) I had the same change under test here, so rather than send a duplicate patch, here are the results. I had already run the same diff through a syzbot test. Quoting the result for reference, since it went to linux-kernel and not to linux-pci: > syzbot has tested the proposed patch and the reproducer did not trigger any issue: > > Reported-by: [email protected] > Tested-by: [email protected] > > Tested on: > > commit: ba5cc80f Merge branch 'for-next/core' into for-kernelci > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git > console output: https://syzkaller.appspot.com/x/log.txt?x=15898149580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=ccf4bea59f67007 > dashboard link: https://syzkaller.appspot.com/bug?extid=7134530b25073b4ef373 > userspace arch: arm64 > patch: https://syzkaller.appspot.com/x/patch.diff?x=1431e132580000 I also tested it locally, on v7.2-rc4 arm64 defconfig under qemu 9.2, with and without this hunk, over every offset and width on an I/O BAR. The unaligned 2- and 4-byte accesses go from oopsing to -EINVAL in both directions, and every aligned access is unchanged. Widths of 3, 5 and 8 return -EINVAL before and after, so the IS_ALIGNED() point the bot raised makes no difference in practice: with a non-power-of-two count the test is meaningless, and the switch rejects the width anyway. Tested-by: Rihyeon Kim <[email protected]> I wonder if it is worth mentioning in the commit log that the two directions are not the same here. You already say pread64() hits it too, but pci_write_resource() calls security_locked_down() with LOCKDOWN_PCI_ACCESS while pci_read_resource() has no such check, so with lockdown at integrity or above the write is refused and the read still faults. Both need root either way, since the attribute is 0600, so maybe it is noise; feel free to ignore. I went through the same thing in the syzbot thread earlier today, if any of it is useful: https://lore.kernel.org/all/[email protected]/ Thanks, Rihyeon Kim