[PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Junrui Luo]

rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
index into the LMT map table to read another function's LMTLINE
physical base address and copy it into the caller's own LMT map table
entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
IRQ source, but req->base_pcifunc is a separate payload field and is
not sanitized.

Reject the request with -EPERM when the caller and base function do
not share a parent PF.

Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
index d2163da28d18..0c27b4b669f1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
@@ -178,6 +178,13 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
 	 * pcifunc (will be the one who is calling this mailbox).
 	 */
 	if (req->base_pcifunc) {
+		/* Only allow LMTLINE sharing within the same PF, so that a
+		 * PCI function cannot hijack another PF's LMTLINE region.
+		 */
+		if (rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
+		    rvu_get_pf(rvu->pdev, req->base_pcifunc))
+			return -EPERM;
+
 		/* Calculating the LMT table index equivalent to primary
 		 * pcifunc.
 		 */

---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20260524-fixes-33bb6d8cccf8

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Jakub Kicinski]

On Sun, 24 May 2026 15:29:29 +0800 Junrui Luo wrote:
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>

Really? I thought I saw this reported in Sashiko..

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260520154157.1439319-1-michael.bommarito@gmail.com

Either way, Marvell folks - please review.

Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Yuhao Jiang]

Hi Jakub,

I worked with Junrui on discovering this bug and preparing the patch.
I found the bug and reported it to Junrui, and he helped write the
patch. There may be some overlap with other work.

Thanks.

On Tue, May 26, 2026 at 8:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sun, 24 May 2026 15:29:29 +0800 Junrui Luo wrote:
> > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
>
> Really? I thought I saw this reported in Sashiko..
>
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260520154157.1439319-1-michael.bommarito@gmail.com
>
> Either way, Marvell folks - please review.



-- 
Yuhao Jiang

Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Jakub Kicinski]

On Tue, 26 May 2026 20:46:46 -0500 Yuhao Jiang wrote:
> Hi Jakub,
> 
> I worked with Junrui on discovering this bug and preparing the patch.
> I found the bug and reported it to Junrui, and he helped write the
> patch. There may be some overlap with other work.

Please don't top post on the list.

Junrui, please describe your discovery process.

> On Tue, May 26, 2026 at 8:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Sun, 24 May 2026 15:29:29 +0800 Junrui Luo wrote:  
> > > Reported-by: Yuhao Jiang <danisjiang@gmail.com>  
> >
> > Really? I thought I saw this reported in Sashiko..
> >
> > https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260520154157.1439319-1-michael.bommarito@gmail.com
> >
> > Either way, Marvell folks - please review.  

Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Junrui Luo]

On Tue, May 26, 2026 at 06:52:24PM -0700, Jakub Kicinski wrote:
> Junrui, please describe your discovery process.

Hi Jakub,

Yuhao forwarded the report to me, and I investigated the issue and wrote
the patch. Sorry for missing the earlier report on Sashiko, and thanks for
the link.

Thanks,
Junrui Luo

RE: [EXTERNAL] Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Geethasowjanya Akula]

>-----Original Message-----
>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Wednesday, May 27, 2026 7:22 AM
>To: Yuhao Jiang <danisjiang@gmail.com>
>Cc: Junrui Luo <moonafterrain@outlook.com>; Sunil Kovvuri Goutham
><sgoutham@marvell.com>; Linu Cherian <lcherian@marvell.com>;
>Geethasowjanya Akula <gakula@marvell.com>; Hariprasad Kelam
><hkelam@marvell.com>; Subbaraya Sundeep Bhatta <sbhatta@marvell.com>;
>Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
><davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Paolo
>Abeni <pabeni@redhat.com>; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org; stable@vger.kernel.org
>Subject: [EXTERNAL] Re: [PATCH net] octeontx2-af: cn10k: restrict LMTLINE
>sharing to same PF
>On Tue, 26 May 2026 20:46:46 -0500 Yuhao Jiang wrote:
>> Hi Jakub,
>>
>> I worked with Junrui on discovering this bug and preparing the patch.
>> I found the bug and reported it to Junrui, and he helped write the
>> patch. There may be some overlap with other work.
>
>Please don't top post on the list.
>
>Junrui, please describe your discovery process.
>
>> On Tue, May 26, 2026 at 8:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
>> >
>> > On Sun, 24 May 2026 15:29:29 +0800 Junrui Luo wrote:
>> > > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
>> >
>> > Really? I thought I saw this reported in Sashiko..
>> >
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__netdev-2Dai.bot
>> > s.linux.dev_sashiko_-23_patchset_20260520154157.1439319-2D1-
>2Dmichae
>> > l.bommarito-
>40gmail.com&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=UiEt_nUe
>> >
>YFctu7JVLXVlXDhTmq_EAfooaZEYInfGuEQ&m=ESyWUuC7cOhVRmobPkCa2wZp
>UJil1G
>> > km_eJqp-iBzx2soczScJlUupDstoIztUIo&s=J8p73boIdnnkY-
>tzhEXMXXE6W0qp5sC
>> > HAZFQ0FjEugE&e=
>> >
>> > Either way, Marvell folks - please review.

Hi Junrui and Jakub,

This patch enforces that the requester’s pcifunc and req->base_pcifunc belong to the same PF.
However, this assumption is not always valid.
We have valid use cases where LMTST lines are intentionally shared across multiple PFs. In such scenarios, 
the base_pcifunc may legitimately belong to a different PF, and restricting access to the same PF would 
break these existing use cases.
  

Re: [EXTERNAL] [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Junrui Luo]

On Wed, May 27, 2026 at 05:20:12AM +0000, Geethasowjanya Akula wrote:
> Hi Junrui and Jakub,
> 
> This patch enforces that the requester’s pcifunc and req->base_pcifunc belong to the same PF.
> However, this assumption is not always valid.
> We have valid use cases where LMTST lines are intentionally shared across multiple PFs. In such scenarios, 
> the base_pcifunc may legitimately belong to a different PF, and restricting access to the same PF would 
> break these existing use cases.
   
Thanks for the review. To preserve cross-PF sharing while still
restricting VF callers, would the check below match your expectation?

	if (is_vf(req->hdr.pcifunc) &&
	    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
	    rvu_get_pf(rvu->pdev, req->base_pcifunc))
	        return -EPERM;

Thanks,
Junrui Luo

RE: [EXTERNAL] [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Geethasowjanya Akula]

>-----Original Message-----
>From: Junrui Luo <moonafterrain@outlook.com>
>Sent: Thursday, May 28, 2026 9:58 PM
>To: Geethasowjanya Akula <gakula@marvell.com>
>Cc: Jakub Kicinski <kuba@kernel.org>; Yuhao Jiang <danisjiang@gmail.com>;
>Sunil Kovvuri Goutham <sgoutham@marvell.com>; Linu Cherian
><lcherian@marvell.com>; Hariprasad Kelam <hkelam@marvell.com>;
>Subbaraya Sundeep Bhatta <sbhatta@marvell.com>; Andrew Lunn
><andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
>Dumazet <edumazet@google.com>; Paolo Abeni <pabeni@redhat.com>;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
>Subject: Re: [EXTERNAL] [PATCH net] octeontx2-af: cn10k: restrict LMTLINE
>sharing to same PF
>On Wed, May 27, 2026 at 05:20:12AM +0000, Geethasowjanya Akula wrote:
>> Hi Junrui and Jakub,
>>
>> This patch enforces that the requester’s pcifunc and req->base_pcifunc
>belong to the same PF.
>> However, this assumption is not always valid.
>> We have valid use cases where LMTST lines are intentionally shared
>> across multiple PFs. In such scenarios, the base_pcifunc may
>> legitimately belong to a different PF, and restricting access to the same PF
>would break these existing use cases.
>
>Thanks for the review. To preserve cross-PF sharing while still restricting VF
>callers, would the check below match your expectation?
>
>	if (is_vf(req->hdr.pcifunc) &&
>	    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
>	    rvu_get_pf(rvu->pdev, req->base_pcifunc))
>	        return -EPERM;

Hi Junrui,

Thanks for the update,
Restricting only VF callers from accessing LMTLINEs across PF boundaries makes sense from a security standpoint.
The changes  aligns with our expectations.
LGTM.

Geetha.
>
>Thanks,
>Junrui Luo

[PATCH net v2] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF

[Junrui Luo]

rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
index into the LMT map table to read another function's LMTLINE
physical base address and copy it into the caller's own LMT map table
entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
IRQ source, but req->base_pcifunc is a separate payload field and is
not sanitized.

Reject with -EPERM when a VF caller and the base function do not share a
parent PF. PF callers are trusted and may still share LMTLINEs across
PFs.

Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Changes in v2:
- Restrict the check to VF callers only. PF callers are trusted and may
  still share LMTLINEs across PFs.
- Link to v1: https://lore.kernel.org/r/SYBPR01MB7881F8D11D2930BB84215253AF0D2@SYBPR01MB7881.ausprd01.prod.outlook.com
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
index d2163da28d18..33f25e2fc262 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
@@ -178,6 +178,14 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
 	 * pcifunc (will be the one who is calling this mailbox).
 	 */
 	if (req->base_pcifunc) {
+		/* A VF is untrusted and must not redirect its LMTLINE to
+		 * another PF's region, so confine VF callers to their own PF.
+		 */
+		if (is_vf(req->hdr.pcifunc) &&
+		    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
+		    rvu_get_pf(rvu->pdev, req->base_pcifunc))
+			return -EPERM;
+
 		/* Calculating the LMT table index equivalent to primary
 		 * pcifunc.
 		 */

---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20260601-fixes-a06620632bac

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

RE: [EXTERNAL] [PATCH net v2] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF

[Geethasowjanya Akula]

>-----Original Message-----
>From: Junrui Luo <moonafterrain@outlook.com>
>Sent: Monday, June 1, 2026 11:25 AM
>To: Sunil Kovvuri Goutham <sgoutham@marvell.com>; Linu Cherian
><lcherian@marvell.com>; Geethasowjanya Akula <gakula@marvell.com>;
>Hariprasad Kelam <hkelam@marvell.com>; Subbaraya Sundeep Bhatta
><sbhatta@marvell.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David S.
>Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
>Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Yuhao Jiang
><danisjiang@gmail.com>; stable@vger.kernel.org; Junrui Luo
><moonafterrain@outlook.com>
>Subject: [EXTERNAL] [PATCH net v2] octeontx2-af: cn10k: restrict VF LMTLINE
>sharing to its own PF
>rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index
>into the LMT map table to read another function's LMTLINE physical base address
>and copy it into the caller's own LMT map table entry. The mailbox dispatcher
>authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a
>separate payload field and is not sanitized.
>
>Reject with -EPERM when a VF caller and the base function do not share a parent
>PF. PF callers are trusted and may still share LMTLINEs across PFs.
>
>Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST
>regions")
>Reported-by: Yuhao Jiang <danisjiang@gmail.com>
>Cc: stable@vger.kernel.org
>Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
>---
>Changes in v2:
>- Restrict the check to VF callers only. PF callers are trusted and may
>  still share LMTLINEs across PFs.
>- Link to v1: https://urldefense.proofpoint.com/v2/url?u=https-
>3A__lore.kernel.org_r_SYBPR01MB7881F8D11D2930BB84215253AF0D2-
>40SYBPR01MB7881.ausprd01.prod.outlook.com&d=DwICaQ&c=nKjWec2b6R0m
>OyPaz7xtfQ&r=UiEt_nUeYFctu7JVLXVlXDhTmq_EAfooaZEYInfGuEQ&m=xuYymVG
>Ze1qq-oeBKE-_xOE_HuutAdE4D-
>lF9ezsL5AvB8RYG06YF9gySBv8fXhy&s=DKDPlH9M4tsGPjYPWOjPXQTKFR_spOogL
>CfJW1rIagI&e=
>---
> drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
>diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
>b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
>index d2163da28d18..33f25e2fc262 100644
>--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
>+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
>@@ -178,6 +178,14 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu
>*rvu,
> 	 * pcifunc (will be the one who is calling this mailbox).
> 	 */
> 	if (req->base_pcifunc) {
>+		/* A VF is untrusted and must not redirect its LMTLINE to
>+		 * another PF's region, so confine VF callers to their own PF.
>+		 */
>+		if (is_vf(req->hdr.pcifunc) &&
>+		    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
>+		    rvu_get_pf(rvu->pdev, req->base_pcifunc))
>+			return -EPERM;
>+
> 		/* Calculating the LMT table index equivalent to primary
> 		 * pcifunc.
> 		 */
>
>---
>base-commit: c369299895a591d96745d6492d4888259b004a9e
>change-id: 20260601-fixes-a06620632bac
>
>Best regards,
>--
>Junrui Luo <moonafterrain@outlook.com>
Reviewed-by: Geetha sowjanya <gakula@marvell.com>

Re: [PATCH net v2] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF

[Paolo Abeni]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF

This patch tries to plug a privilege boundary in the LMTLINE setup
mailbox by rejecting -EPERM when a VF caller's parent PF differs from
the parent PF of req->base_pcifunc. It carries Fixes: 893ae97214c3
and Cc: stable@vger.kernel.org.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> index d2163da28d18..33f25e2fc262 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> @@ -178,6 +178,14 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
>  	 * pcifunc (will be the one who is calling this mailbox).
>  	 */
>  	if (req->base_pcifunc) {
> +		/* A VF is untrusted and must not redirect its LMTLINE to
> +		 * another PF's region, so confine VF callers to their own PF.
> +		 */
> +		if (is_vf(req->hdr.pcifunc) &&
> +		    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
> +		    rvu_get_pf(rvu->pdev, req->base_pcifunc))
> +			return -EPERM;
> +

[Critical]
Can this check still be bypassed via the FUNC bits of base_pcifunc?

rvu_get_pf() only inspects the upper PF bits of the pcifunc (shift 10
on OTX2, shift 9 on CN20K), but RVU_PFVF_FUNC_MASK is 0x3FF, so the
FUNC field a VF can set in req->base_pcifunc spans 0..1023:

  static inline int rvu_get_pf(struct pci_dev *pdev, u16 pcifunc)
  {
          if (is_cn20k(pdev))
                  return (pcifunc >> RVU_CN20K_PFVF_PF_SHIFT) &
                          RVU_CN20K_PFVF_PF_MASK;
          else
                  return (pcifunc >> RVU_OTX2_PFVF_PF_SHIFT) &
                          RVU_OTX2_PFVF_PF_MASK;
  }

After the new check passes, base_pcifunc is fed straight into
rvu_get_lmtst_tbl_index(), where the index is computed from the full
FUNC field and LMT_MAX_VFS = 256:

  #define LMT_MAX_VFS             256

  static u32 rvu_get_lmtst_tbl_index(struct rvu *rvu, u16 pcifunc)
  {
          return ((rvu_get_pf(rvu->pdev, pcifunc) * LMT_MAX_VFS) +
                  (pcifunc & RVU_PFVF_FUNC_MASK)) * LMT_MAPTBL_ENTRY_SIZE;
  }

So a FUNC value >= 256 wraps into the next PF's slot range. Worked
example on OTX2: a VF on PF=0 (req->hdr.pcifunc = 0x0001) sets
req->base_pcifunc = 0x012C (300). is_vf() is true, and
rvu_get_pf(0x012C) = (300 >> 10) & PF_MASK = 0, equal to the caller's
PF, so the new -EPERM path is not taken.

rvu_get_lmtst_tbl_index() then yields (0 * 256 + 300) * 16 = 4800,
which is the slot for PF=1 FUNC=44 (1 * 256 + 44 = 300).

  pri_tbl_idx = rvu_get_lmtst_tbl_index(rvu, req->base_pcifunc);
  err = lmtst_map_table_ops(rvu, pri_tbl_idx, &val, LMT_TBL_OP_READ);
  ...
  err = rvu_update_lmtaddr(rvu, req->hdr.pcifunc, val);

That reads PF=1's physical LMT base address and copies it into the
attacker VF's own LMT map entry, which is the cross-PF redirection the
patch is intended to prevent.

The same wrap is reachable on CN20K, e.g. base_pcifunc = 511 lands in
PF=1 FUNC=255's slot since PF_SHIFT is 9 there.

Would it make sense to also reject base_pcifunc whose FUNC field is
out of range, for example by additionally requiring
(req->base_pcifunc & RVU_PFVF_FUNC_MASK) < LMT_MAX_VFS, or by looking
base_pcifunc up via rvu_get_pfvf() / is_pffunc_map_valid() and
confirming it is a real attached function under the same parent PF?