From: sashiko-bot@kernel.org
To: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()
Date: Mon, 06 Jul 2026 18:05:56 +0000 [thread overview]
Message-ID: <20260706180556.BBDC71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706175423.98305-1-kwilczynski@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] KASAN Slab-Out-of-Bounds Read due to blind 32-bit cast on dynamically allocated buffer.
- [High] Missing kernel lockdown checks in legacy PCI sysfs interfaces allows Secure Boot bypass.
--
commit be452ca0a927e25b05ef8e9af9aca2fcb7ecfaa3
Author: Krzysztof Wilczyński <kwilczynski@kernel.org>
alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()
This patch corrects the argument order for outb(), outw(), and outl()
in the Alpha architecture's pci_legacy_write() function. The previous
implementation wrote the port number as data to the address derived from
the user-supplied value. By swapping the arguments to match the expected
value and port order, the intended I/O port writes are now performed
correctly.
> diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
> index 94dbc470cd6c0..7050f0f7fe3d7 100644
> --- a/arch/alpha/kernel/pci-sysfs.c
> +++ b/arch/alpha/kernel/pci-sysfs.c
> @@ -224,17 +224,17 @@ int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val, size_t size)
[Severity: High]
This is a pre-existing issue, but could the caller of this function trigger a
KASAN slab-out-of-bounds read when passing the val argument?
Looking at drivers/pci/pci-sysfs.c:pci_write_legacy_io(), the buffer is cast
directly to a 32-bit integer before calling pci_legacy_write():
return pci_legacy_write(bus, off, *(u32 *)buf, count);
If a user performs a 1-byte or 2-byte write to the legacy_io sysfs file,
fs/kernfs/file.c:kernfs_fop_write_iter() dynamically allocates buf to the
exact write length plus a null terminator:
buf = kmalloc(len + 1, GFP_KERNEL);
Unconditionally casting this smaller buffer to u32 * and dereferencing it
reads past the allocation boundary. Should the buffer cast be bounded by the
count parameter?
[Severity: High]
This is also a pre-existing issue, but does this legacy write path allow a
Kernel Lockdown and Secure Boot bypass?
Unlike standard resource handlers like pci_write_resource(), the generic
handlers in drivers/pci/pci-sysfs.c for legacy endpoints completely omit
the security_locked_down() checks.
For example, drivers/pci/pci-sysfs.c:pci_write_legacy_io() allows writes:
static ssize_t pci_write_legacy_io(struct file *filp, struct kobject *kobj,
const struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
And drivers/pci/pci-sysfs.c:pci_mmap_legacy_mem() allows raw memory access:
static int pci_mmap_legacy_mem(struct file *filp, struct kobject *kobj,
const struct bin_attribute *attr,
struct vm_area_struct *vma)
Neither function checks security_locked_down(LOCKDOWN_PCI_ACCESS). Can a
privileged user exploit this to write directly to hardware I/O ports or mmap
legacy memory?
>
> switch(size) {
> case 1:
> - outb(port, val);
> + outb(val, port);
> return 1;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175423.98305-1-kwilczynski@kernel.org?part=1
next prev parent reply other threads:[~2026-07-06 18:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 17:54 [PATCH v2] alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write() Krzysztof Wilczyński
2026-07-06 18:05 ` sashiko-bot [this message]
2026-07-08 10:56 ` Magnus Lindholm
2026-07-10 20:32 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260706180556.BBDC71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.