From: sashiko-bot@kernel.org
To: "Dipayaan Roy" <dipayanroy@linux.microsoft.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net, v2] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR
Date: Thu, 30 Apr 2026 18:59:31 +0000 [thread overview]
Message-ID: <20260430185931.B6051C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <afJUszROT+yKjth0@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incomplete fix: Missing bounds and alignment validation for the doorbell page offset (`db_page_off`), leaving the driver vulnerable to out-of-bounds MMIO accesses and arbitrary physical memory mapping.
- [High] Missing minimum BAR0 size validation for fixed-offset configuration registers.
- [Low] Duplicate macro definitions for SMC_APERTURE_BITS and related constants.
- [Low] Dangling sentence fragment in the commit message.
--
commit a719bcc10e344c9685c78dde6408c1022c5a812e
Author: Dipayaan Roy <dipayanroy@linux.microsoft.com>
net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR
This commit validates the SHM offset read from BAR0 to prevent out-of-bounds
and unaligned accesses. It computes safely by subtracting from bar0_size
instead of adding.
> without validating the offset read from hardware. If the register
> returns a garbage value that is neither within bar 0 bounds nor aligned
> to the 4-byte granularity, thus causing the alignment fault.
This isn't a bug, but there appears to be a dangling sentence fragment left
over in the commit message.
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 098fbda0d128..d8e816882f02 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -43,8 +43,9 @@ static u64 mana_gd_r64(struct gdma_context *g, u64 offset)
> static int mana_gd_init_pf_regs(struct pci_dev *pdev)
> {
> struct gdma_context *gc = pci_get_drvdata(pdev);
> - void __iomem *sriov_base_va;
> + u64 remaining_barsize;
> u64 sriov_base_off;
> + u64 sriov_shm_off;
>
> gc->db_page_size = mana_gd_r32(gc, GDMA_PF_REG_DB_PAGE_SIZE) & 0xFFFF;
Is gc->bar0_size guaranteed to be large enough before this initial read?
If a device exposes an unusually small BAR0, could this read from the fixed
GDMA_PF_REG_DB_PAGE_SIZE offset result in an out-of-bounds MMIO access
before the dynamic offset validations are reached?
[ ... ]
> @@ -73,10 +74,28 @@ static int mana_gd_init_pf_regs(struct pci_dev *pdev)
> gc->phys_db_page_base = gc->bar0_pa + gc->db_page_off;
>
> sriov_base_off = mana_gd_r64(gc, GDMA_SRIOV_REG_CFG_BASE_OFF);
> + if (sriov_base_off >= gc->bar0_size ||
> + gc->bar0_size - sriov_base_off <
> + GDMA_PF_REG_SHM_OFF + sizeof(u64) ||
> + !IS_ALIGNED(sriov_base_off, sizeof(u64))) {
> + dev_err(gc->dev,
> + "SRIOV base offset 0x%llx out of range or unaligned (BAR0 size 0x%llx)\n",
> + sriov_base_off, (u64)gc->bar0_size);
> + return -EPROTO;
> + }
While this cleanly fixes the bounds and alignment checks for sriov_base_off,
should similar checks be applied to db_page_off which is read just above
this section?
In mana_gd_init_pf_regs():
gc->db_page_off = mana_gd_r64(gc, GDMA_PF_REG_DB_PAGE_OFF);
if (gc->db_page_off >= gc->bar0_size) {
dev_err(gc->dev, ...);
return -EPROTO;
}
Could this leave a regression with out-of-bounds MMIO accesses or alignment
faults if gc->bar0_size - gc->db_page_off is smaller than the required
doorbell page size?
> diff --git a/include/net/mana/shm_channel.h b/include/net/mana/shm_channel.h
> index 5199b41497ff..dbabcfb95daf 100644
> --- a/include/net/mana/shm_channel.h
> +++ b/include/net/mana/shm_channel.h
> @@ -4,6 +4,12 @@
> #ifndef _SHM_CHANNEL_H
> #define _SHM_CHANNEL_H
>
> +#define SMC_APERTURE_BITS 256
> +#define SMC_BASIC_UNIT (sizeof(u32))
> +#define SMC_APERTURE_DWORDS (SMC_APERTURE_BITS / (SMC_BASIC_UNIT * 8))
> +#define SMC_LAST_DWORD (SMC_APERTURE_DWORDS - 1)
> +#define SMC_APERTURE_SIZE (SMC_APERTURE_BITS / 8)
> +
> struct shm_channel {
> struct device *dev;
> void __iomem *base;
Does exporting these macros to the header file result in duplicate
definitions?
It looks like the original definitions might still be present in
drivers/net/ethernet/microsoft/mana/shm_channel.c.
--
Sashiko AI review · https://sashiko.dev/#/patchset/afJUszROT+yKjth0@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net?part=1
next prev parent reply other threads:[~2026-04-30 18:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 18:57 [PATCH net, v2] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR Dipayaan Roy
2026-04-30 18:59 ` sashiko-bot [this message]
2026-05-02 1:53 ` Jakub Kicinski
2026-05-03 3:03 ` Dipayaan Roy
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=20260430185931.B6051C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dipayanroy@linux.microsoft.com \
--cc=sashiko@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.