Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sophon Z" <aiqubits@hotmail.com>
Cc: linux-pci@vger.kernel.org, ojeda@kernel.org
Subject: Re: [PATCH v2] rust: pci: Reject IRQ vector indices that do not fit in u32
Date: Mon, 31 Aug 2026 06:17:42 +0000	[thread overview]
Message-ID: <20260831061742.8A32E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831-fix-pci-irq-vector-index-truncation-v2-1-4030ea7746a9@hotmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `IrqVectorRegistration::index` delegates out-of-bounds validation entirely to the C API `pci_irq_vector`, which triggers a `WARN_ON_ONCE` for sufficiently large indices, potentially causing a kernel panic.
--

commit 1d05a4f88062a655f88b6ab70e939331e2445d7b
Author: Sophon Z <aiqubits@hotmail.com>

rust: pci: Reject IRQ vector indices that do not fit in u32

IrqVectorRegistration::index() accepts a usize, but pci_irq_vector() takes
an unsigned int. This commit adds a checked conversion to prevent wrapping
on 64-bit architectures, returning EINVAL if the index exceeds u32 limits.

> diff --git a/rust/kernel/pci/irq.rs b/rust/kernel/pci/irq.rs
> index 6741046ec1c09..1bf91973cb1f4 100644
> --- a/rust/kernel/pci/irq.rs
> +++ b/rust/kernel/pci/irq.rs
> @@ -151,8 +151,10 @@ pub fn irq_type(&self) -> IrqType {
>      /// [`Self::len()`].
>      #[inline]
>      pub fn index(&self, index: usize) -> Result<IrqVector<'_>> {
> +        let index = u32::try_from(index).map_err(|_| EINVAL)?;

[Severity: High]
This is a pre-existing issue, but does this adequately prevent out-of-bounds
indices from reaching the C API?

Passing an index greater than 65535 (MSI_MAX_INDEX) causes the underlying
C API msi_domain_get_virq() to trigger a WARN_ON_ONCE(index > MSI_MAX_INDEX).
On systems configured with panic_on_warn=1, this leads to a kernel panic.

If a driver exposes IRQ vector selection to userspace without its own bounds
checking, relying on this abstraction to return EINVAL, this could result in
a Denial of Service.

Since self.len() is already known and guaranteed to be at most 2048 for
MSI-X, wouldn't explicitly checking if index >= self.len() be safer and
inherently prevent the warning from being triggered?

> +
>          // SAFETY: `self.dev.as_raw()` is a valid pointer to a `struct pci_dev`.
> -        let irq = unsafe { bindings::pci_irq_vector(self.dev.as_raw(), index as u32) };
> +        let irq = unsafe { bindings::pci_irq_vector(self.dev.as_raw(), index) };
>          if irq < 0 {
>              return Err(Error::from_errno(irq));
>          }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-fix-pci-irq-vector-index-truncation-v2-1-4030ea7746a9@hotmail.com?part=1

      reply	other threads:[~2026-08-31  6:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  6:08 [PATCH v2] rust: pci: Reject IRQ vector indices that do not fit in u32 Sophon Z via B4 Relay
2026-08-31  6:17 ` sashiko-bot [this message]

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=20260831061742.8A32E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aiqubits@hotmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=ojeda@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox