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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox