From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: shao.mingyin@zte.com.cn
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, mani@kernel.org,
kwilczynski@kernel.org, lpieralisi@kernel.org,
kishon@kernel.org, Frank.Li@kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/5] PCI: rebar: Guard pci_rebar_bytes_to_size() against overflow
Date: Fri, 6 Nov 2026 18:37:52 +0200 (EET) [thread overview]
Message-ID: <a9c36a69-a0d3-62af-e5d7-cf99c427a1ff@linux.intel.com> (raw)
In-Reply-To: <20261107002315181vFaB7Y_zoFugWEVkOSGJZ@zte.com.cn>
On Sat, 7 Nov 2026, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> pci_rebar_bytes_to_size() passes its argument straight to
> roundup_pow_of_two(), whose implementation is (1UL << fls(bytes - 1)).
> For bytes == 0 and for values above 2^63, fls() returns 64 and the
> shift count is undefined behavior. A value with bit 63 set cannot be
> encoded either: exactly 2^63 rounds to itself and is encoded as 43,
> outside the 5-bit BAR Size field.
>
> Bail out for bytes == 0 and for any value with bit 63 set; a zero size
> is returned, which encodes the 1 MB minimum. The largest valid BAR size
> is 128 TB, far below the 2^63 boundary, so no legitimate input is
> affected.
>
> Fixes: 192f1bf7559e ("PCI: Add pci_rebar_bytes_to_size()")
This is missing how it can be reproduced with the existing kernel code. If
it's not triggerable, the Fixes tag should be dropped.
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
> ---
> Tested on 7.3.0-next-20261030 (QEMU/TCG x86_64) with a TEST-ONLY hook
> (applied to both kernels) that calls pci_rebar_bytes_to_size() at boot
So no real reproducer?
> with pathological inputs (0, 2^63, U64_MAX) and two sane sizes (1 MB,
> 1 GB), built with CONFIG_UBSAN_SHIFT. No extra hardware is needed.
>
> Unpatched, the 2^63 input is encoded as BAR size 43 (outside the valid
> 0..31 range) and the 0/U64_MAX inputs shift by 64 (UBSAN reports "shift
> exponent 64 is too large for 64-bit type"). With this patch all
> pathological inputs return 0, the two sane sizes are unchanged (1 MB -> 0,
> 1 GB -> 10) and no UBSAN report appears.
>
> unpatched patched
> UBSAN shift-out-of-bounds; size 43 size 0, no UBSAN report
>
> diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
> index 5bbdc9470a31..fd448dc7c322 100644
> --- a/drivers/pci/rebar.c
> +++ b/drivers/pci/rebar.c
> @@ -31,6 +31,13 @@ int pci_rebar_bytes_to_size(u64 bytes)
> {
> int rebar_minsize = ilog2(PCI_REBAR_MIN_SIZE);
>
> + /*
> + * roundup_pow_of_two() is undefined for 0 and above 2^63; any value
> + * with bit 63 set is outside the 5-bit BAR Size field, so bail out.
> + */
> + if (!bytes || bytes & (1ULL << 63))
> + return 0;
Won't this clash with the normal return values? -EINVAL seems better
choice.
...So now you get to add the error handling too.
--
i.
next prev parent reply other threads:[~2026-11-06 16:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 16:23 [PATCH 0/5] PCI: Fix invalid input handling and a NULL dereference shao.mingyin
2026-11-06 16:23 ` [PATCH 1/5] PCI: Reject negative resource alignment order shao.mingyin
2026-11-06 16:39 ` Ilpo Järvinen
2026-11-06 17:13 ` shao.mingyin
2026-11-06 16:23 ` [PATCH 2/5] PCI: of: Bound num_lanes in of_pci_get_equalization_presets() shao.mingyin
2026-11-06 16:23 ` [PATCH 3/5] PCI/ASPM: Skip link-state setup without downstream function 0 shao.mingyin
2026-11-06 16:23 ` [PATCH 4/5] PCI: rebar: Guard pci_rebar_bytes_to_size() against overflow shao.mingyin
2026-11-06 16:37 ` Ilpo Järvinen [this message]
2026-11-06 17:11 ` shao.mingyin
2026-11-06 16:23 ` [PATCH 5/5] PCI: endpoint: Reject a zero interrupt number in raise_irq shao.mingyin
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=a9c36a69-a0d3-62af-e5d7-cf99c427a1ff@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Frank.Li@kernel.org \
--cc=bhelgaas@google.com \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=shao.mingyin@zte.com.cn \
/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.