lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BY3PR18MB47076BEBC13E5C0A36083C43A08E9@BY3PR18MB4707.namprd18.prod.outlook.com>
Date:   Thu, 30 Mar 2023 10:13:10 +0000
From:   Sai Krishna Gajula <saikrishnag@...vell.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Hariprasad Kelam <hkelam@...vell.com>
Subject: Re: [net PATCH 3/7] octeontx2-af: Add validation for lmac type

Please see inline,

> -----Original Message-----
> From: Leon Romanovsky <leon@...nel.org>
> Sent: Thursday, March 30, 2023 11:49 AM
> To: Sai Krishna Gajula <saikrishnag@...vell.com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> Sunil Kovvuri Goutham <sgoutham@...vell.com>;
> richardcochran@...il.com; Hariprasad Kelam <hkelam@...vell.com>
> Subject: Re: [net PATCH 3/7] octeontx2-af: Add validation for lmac type
 
> > From: Hariprasad Kelam <hkelam@...vell.com>
> >
> > Upon physical link change, firmware reports to the kernel about the
> > change along with the details like speed, lmac_type_id, etc.
> > Kernel derives lmac_type based on lmac_type_id received from firmware.
> >
> > In a few scenarios, firmware returns an invalid lmac_type_id, which is
> > resulting in below kernel panic. This patch adds the missing
> > validation of the lmac_type_id field.
> >
> > Internal error: Oops: 96000005 [#1] PREEMPT SMP
> > [   35.321595] Modules linked in:
> > [   35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
> > 5.4.210-g2e3169d8e1bc-dirty #17
> > [   35.337014] Hardware name: Marvell CN103XX board (DT)
> > [   35.344297] Workqueue: events work_for_cpu_fn
> > [   35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)
> > [   35.360267] pc : strncpy+0x10/0x30
> > [   35.366595] lr : cgx_link_change_handler+0x90/0x180
> >
> > Fixes: 61071a871ea6 ("octeontx2-af: Forward CGX link notifications to
> > PFs")
> > Signed-off-by: Hariprasad Kelam <hkelam@...vell.com>
> > Signed-off-by: Sunil Kovvuri Goutham <sgoutham@...vell.com>
> > Signed-off-by: Sai Krishna <saikrishnag@...vell.com>
> > ---
> >  drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
> > b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
> > index 724df6398bbe..180aa84cf1c3 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
> > @@ -1231,6 +1231,13 @@ static inline void link_status_user_format(u64
> lstat,
> >  	linfo->an = FIELD_GET(RESP_LINKSTAT_AN, lstat);
> >  	linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
> >  	linfo->lmac_type_id = FIELD_GET(RESP_LINKSTAT_LMAC_TYPE, lstat);
> > +
> > +	if (linfo->lmac_type_id >= LMAC_MODE_MAX) {
> > +		dev_err(&cgx->pdev->dev, "Unknown lmac_type_id %d
> reported by firmware on cgx port%d:%d",
> > +			linfo->lmac_type_id, cgx->cgx_id, lmac_id);
> > +		return;
> 
> You are keeping old lmac_type, which is out-of-sync now.
> Why don't you do something like that?
> 
> if (linfo->lmac_type_id >= LMAC_MODE_MAX) {
>   strncpy(linfo->lmac_type, "Unknown", LMACTYPE_STR_LEN - 1);
>   return;
> }
> 
> 
We will add the proposed change (Unknown). Since we need to know the firmware reported lmac type ID is proper or not, we will keep dev_err also.

Thanks,
Sai

> > +	}
> > +
> >  	lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
> >  	strncpy(linfo->lmac_type, lmac_string, LMACTYPE_STR_LEN - 1);  }
> > --
> > 2.25.1
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ