From: Greg KH <gregkh@linuxfoundation.org>
To: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: arnd@arndb.de, kees@kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v8 1/2] misc: ibmasm: Fix static out-of-bounds MMIO access during probe
Date: Fri, 31 Jul 2026 13:18:05 +0200 [thread overview]
Message-ID: <2026073120-deplete-bronzing-481c@gregkh> (raw)
In-Reply-To: <20260718073253.96741-2-25181214217@stu.xidian.edu.cn>
On Sat, Jul 18, 2026 at 03:32:52PM +0800, Mingyu Wang wrote:
> The ibmasm driver maps PCI BAR 0 without verifying if the hardware-provided
> resource length is sufficient to cover statically accessed registers.
>
> When evaluating the driver against emulated hardware or during virtual
> device fuzzing, a malformed device may expose a significantly undersized
> BAR 0. This leads to an out-of-bounds (OOB) access when reading or writing
> to registers such as INTR_CONTROL_REGISTER (offset 0x13A4) or mouse
> interrupt controls (offset 0xAC000) during probe. A page fault here
> while holding the idempotent_init_module() lock causes a cascading global
> soft lockup.
In thinking about this some more, isn't that what the "authenticated
PCI" spec is for? We trust this hardware, right? If it gives us an
invalid BAR, bad things can and will happen.
So does this ever happen in a real device? And where are these real
devices? What types of systems are they and are they even still being
used?
>
> Fix this by storing the mapped size in 'struct service_processor' and
> ensuring the BAR is at least large enough to cover the highest statically
> accessed hardware register before calling pci_ioremap_bar(). This highest
> static access (offset 0xAC1FC) occurs via the display_depth() macro
> during ibmasmfs filesystem initialization.
>
> Fixes: bdbeed75b288 ("pci: use pci_ioremap_bar() in drivers/misc")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> ---
> drivers/misc/ibmasm/ibmasm.h | 1 +
> drivers/misc/ibmasm/lowlevel.h | 3 +++
> drivers/misc/ibmasm/module.c | 13 +++++++++++++
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/misc/ibmasm/ibmasm.h b/drivers/misc/ibmasm/ibmasm.h
> index a5ced88ca923..8d69198bf10f 100644
> --- a/drivers/misc/ibmasm/ibmasm.h
> +++ b/drivers/misc/ibmasm/ibmasm.h
> @@ -140,6 +140,7 @@ struct service_processor {
> struct list_head node;
> spinlock_t lock;
> void __iomem *base_address;
> + resource_size_t mapped_size;
> unsigned int irq;
> struct command *current_command;
> struct command *heartbeat;
> diff --git a/drivers/misc/ibmasm/lowlevel.h b/drivers/misc/ibmasm/lowlevel.h
> index 25f1ed07c3c5..970d30478c7b 100644
> --- a/drivers/misc/ibmasm/lowlevel.h
> +++ b/drivers/misc/ibmasm/lowlevel.h
> @@ -33,6 +33,9 @@
> #define INTR_STATUS_REGISTER 0x13A0
> #define INTR_CONTROL_REGISTER 0x13A4
>
> +/* Highest static MMIO offset accessed during probe (display_depth during fs init) */
> +#define IBMASM_MAX_REG_OFFSET 0xAC1FC
Where did this value come from?
> +
> #define SCOUT_COM_A_BASE 0x0000
> #define SCOUT_COM_B_BASE 0x0100
> #define SCOUT_COM_C_BASE 0x0200
> diff --git a/drivers/misc/ibmasm/module.c b/drivers/misc/ibmasm/module.c
> index 4509c15a76a8..87d4d698a5ff 100644
> --- a/drivers/misc/ibmasm/module.c
> +++ b/drivers/misc/ibmasm/module.c
> @@ -93,6 +93,19 @@ static int ibmasm_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
> }
>
> sp->irq = pdev->irq;
> + sp->mapped_size = pci_resource_len(pdev, 0);
> +
> + /*
> + * Ensure BAR 0 is large enough to cover the highest statically
> + * accessed hardware register (IBMASM_MAX_REG_OFFSET).
> + */
> + if (sp->mapped_size < IBMASM_MAX_REG_OFFSET + 4) {
> + dev_err(sp->dev, "PCI BAR0 too small, need at least %zu bytes\n",
> + (size_t)(IBMASM_MAX_REG_OFFSET + 4));
I feel like if we start taking this type of patch, you will need to do
it for EVERY PCI driver in the kernel, right?
Again, Linux trusts PCI devices, so is this even needed?
thanks,
greg k-h
next prev parent reply other threads:[~2026-07-31 11:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 7:32 [PATCH v8 0/2] misc: ibmasm: Fix out-of-bounds MMIO accesses Mingyu Wang
2026-07-18 7:32 ` [PATCH v8 1/2] misc: ibmasm: Fix static out-of-bounds MMIO access during probe Mingyu Wang
2026-07-31 11:18 ` Greg KH [this message]
2026-07-31 13:57 ` Mingyu Wang
2026-07-31 14:17 ` Greg KH
2026-08-01 2:58 ` Mingyu Wang
2026-08-01 6:52 ` Greg KH
2026-08-01 7:07 ` [PATCH] misc: ibmasm: Remove obsolete IBM Remote Supervisor Adapter driver Mingyu Wang
2026-08-01 9:23 ` Arnd Bergmann
2026-07-18 7:32 ` [PATCH v8 2/2] misc: ibmasm: Fix dynamic out-of-bounds MMIO access via malicious MFA Mingyu Wang
2026-07-31 11:18 ` Greg KH
2026-07-31 13:58 ` Mingyu Wang
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=2026073120-deplete-bronzing-481c@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=25181214217@stu.xidian.edu.cn \
--cc=arnd@arndb.de \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox