Re: [PATCH] PCI: sysfs: Reject unaligned resource I/O port accesses
From: David Laight
Date: Wed Sep 23 2026 - 17:51:28 EST
On Wed, 23 Sep 2026 15:55:18 -0500
Bjorn Helgaas <helgaas@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Closes: https://syzkaller.appspot.com/bug?extid=7134530b25073b4ef373
> > > Signed-off-by: Deepanshu Kartikey <kartikey406@xxxxxxxxx>
> > > ---
> > > 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@xxxxxxxxxxxxxxx?
>
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