[PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses

[PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses

[Deepanshu Kartikey]

pci_resource_io() validates that off+count stays within the BAR's
range but never checks that the resulting port is aligned to the
access size. A pwrite64()/pread64() on a resourceN file with an odd
offset and count=2 or count=4 reaches outw()/outl() with a misaligned
address. On arm64 this becomes a store/load to a Device-memory
mapping (PCI_IOBASE + port), which architecturally requires natural
alignment, causing an alignment fault and kernel oops.

Reject misaligned accesses before they reach the low-level accessor.

Reported-by: syzbot+7134530b25073b4ef373@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7134530b25073b4ef373
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 drivers/pci/pci-sysfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 5ec0b245a69b..72f0404a34e9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1175,6 +1175,9 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
 	if (port + count - 1 > pci_resource_end(pdev, bar))
 		return -EINVAL;
 
+	if (!IS_ALIGNED(port, count))
+		return -EINVAL;
+
 	switch (count) {
 	case 1:
 		if (write)
-- 
2.43.0

Re: [PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `IS_ALIGNED()` macro is invoked with a user-controlled argument (`count`) that is not guaranteed to be a power of two.
--

--- Patch [1]: [PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses ---
commit 5ca53d551b5755e8c03169b8a70d53f035905df7
Author: Deepanshu Kartikey <kartikey406@gmail.com>

PCI: sysfs: Reject unaligned resource I/O port accesses

This commit adds a check in pci_resource_io() to validate that the requested
port is aligned to the access size. This prevents alignment faults and kernel
oopses on architectures like arm64 when accessing Device-memory mappings.

Closes: https://syzkaller.appspot.com/bug?extid=7134530b25073b4ef373

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

[Severity: Low]
Does this code call IS_ALIGNED() with an unvalidated user input for the
alignment argument?

The IS_ALIGNED() macro strictly requires its alignment argument to be a power
of two, but count comes from user space (via pread or pwrite) and could be a
non-power-of-two value like 3. Passing a non-power-of-two value results in
meaningless bitwise operations.

While the subsequent switch (count) statement catches and rejects invalid
sizes by returning -EINVAL, would it be more appropriate to perform this
alignment check after validating that count is actually 1, 2, or 4?

>  	switch (count) {
>  	case 1:
>  		if (write)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260809045946.15638-1-kartikey406@gmail.com?part=1

Re: [PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses

[Rihyeon Kim]

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: syzbot+7134530b25073b4ef373@syzkaller.appspotmail.com
> Tested-by: syzbot+7134530b25073b4ef373@syzkaller.appspotmail.com
>
> 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 <rihyeon8648@gmail.com>

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/20260809012855.109608-1-rihyeon8648@gmail.com/

Thanks,
Rihyeon Kim