drivers/pci/pci-sysfs.c | 3 +++ 1 file changed, 3 insertions(+)
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
On Sun, Aug 9, 2026 at 10:29 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> 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
>
Please let me know the status of this patch.
Thanks
Deepanshu
On Wed, Sep 23, 2026 at 09:05:15AM +0530, Deepanshu Kartikey wrote:
> On Sun, Aug 9, 2026 at 10:29 AM Deepanshu Kartikey
> <kartikey406@gmail.com> wrote:
> >
> > 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
> >
> Please let me know the status of this patch.
What do you think of the sashiko comments:
https://lore.kernel.org/all/20260809051652.36BA31F000E9@smtp.kernel.org?
On Wed, 23 Sep 2026 15:55:18 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Sep 23, 2026 at 09:05:15AM +0530, Deepanshu Kartikey wrote:
> > On Sun, Aug 9, 2026 at 10:29 AM Deepanshu Kartikey
> > <kartikey406@gmail.com> wrote:
> > >
> > > 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))
I think that test can ignore count.
> > > return -EINVAL;
> > >
> > > + if (!IS_ALIGNED(port, count))
> > > + return -EINVAL;
> > > +
> > > switch (count) {
> > > case 1:
> > > if (write)
> > > --
> > > 2.43.0
> > >
> > Please let me know the status of this patch.
>
> What do you think of the sashiko comments:
> https://lore.kernel.org/all/20260809051652.36BA31F000E9@smtp.kernel.org?
>
You could just add 'if (port & 1) return -EINVAL;' to the 'case 2:' branch,
and a similar '& 3' to the 'case 4:' one.
Did it miss that loff_t is (probably) 64bit on 32bit?
Or do large offsets get detected earlier?
David
On Thu, Sep 24, 2026 at 3:21 AM David Laight <david.laight.linux@gmail.com> wrote: > > On Wed, 23 Sep 2026 15:55:18 -0500 > Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > What do you think of the sashiko comments: > > https://lore.kernel.org/all/20260809051652.36BA31F000E9@smtp.kernel.org? > > > > You could just add 'if (port & 1) return -EINVAL;' to the 'case 2:' branch, > and a similar '& 3' to the 'case 4:' one. > > Did it miss that loff_t is (probably) 64bit on 32bit? > Or do large offsets get detected earlier? > > David Thanks David for the suggestion. I have send patch v2 Thanks Deepanshu
On Sun, Aug 09, 2026 at 10:29:46AM +0530, Deepanshu Kartikey wrote: > 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> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> - Mani -- மணிவண்ணன் சதாசிவம்
On Sun, Aug 9, 2026 at 10:29 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> 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
>
Gentle Reminder. Please let me know the status of this patch
Thanks
Deepanshu
On Fri, Aug 21, 2026 at 07:16:32AM +0530, Deepanshu Kartikey wrote:
> On Sun, Aug 9, 2026 at 10:29 AM Deepanshu Kartikey
> <kartikey406@gmail.com> wrote:
> >
> > 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
> >
>
> Gentle Reminder. Please let me know the status of this patch
We're in the middle of the merge window, so won't be adding new
material until after v7.3-rc1 (probably Aug 31).
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
© 2016 - 2026 Red Hat, Inc.