netdev - Re: [PATCH net-next v1 1/1] net: macb: fix negative max

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] [day] [month] [year] [list]

Message-ID: <2ff1e2ec-c192-c293-d8e3-d23a1f551c09@microchip.com>
Date:   Fri, 10 Jun 2022 13:06:51 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <o.rempel@...gutronix.de>, <Nicolas.Ferre@...rochip.com>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>
CC:     <kernel@...gutronix.de>, <linux-kernel@...r.kernel.org>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v1 1/1] net: macb: fix negative max_mtu size for
 sama5d3

On 10.06.2022 12:45, Oleksij Rempel wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Microchip SAMA5D3 the JML will return null. 

Should be because it hasn't been configured yet. It is configured later on
macb_init_hw() which is called on open.

So, after header and FCS length
> subtraction we will get negative max_mtu size. This issue was directly
> affecting DSA drivers with MTU support (for example KSZ9477).
> 
> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> ---
>  drivers/net/ethernet/cadence/macb_main.c | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index d89098f4ede8..c7e1c9ac9809 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -4913,10 +4913,24 @@ static int macb_probe(struct platform_device *pdev)
> 
>         /* MTU range: 68 - 1500 or 10240 */
>         dev->min_mtu = GEM_MTU_MIN_SIZE;
> -       if (bp->caps & MACB_CAPS_JUMBO)
> -               dev->max_mtu = gem_readl(bp, JML) - ETH_HLEN - ETH_FCS_LEN;
> -       else
> +       if (bp->caps & MACB_CAPS_JUMBO) {
> +               u32 val;
> +
> +               if (bp->jumbo_max_len)
> +                       val = bp->jumbo_max_len;
> +               else
> +                       val = gem_readl(bp, JML);
> +
> +               if (val < ETH_DATA_LEN) {
> +                       dev_warn(&pdev->dev, "Suspicious max MTU size (%u), overwriting to %u\n",
> +                                val, ETH_DATA_LEN);
> +                       dev->max_mtu = ETH_DATA_LEN;
> +               } else {
> +                       dev->max_mtu = val - ETH_HLEN - ETH_FCS_LEN;
> +               }
> +       } else {

Maybe, simply would be to also check bp->jumbo_max_len and have something like:
	if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len)
		dev->max_mtu = bp->jumbo_max_len - ETH_HLEN - ETH_FCS_LEN;

if that works as it is the same condition used when updating JML in
macb_init_hw().

Thank you,
Claudiu Beznea

>                 dev->max_mtu = ETH_DATA_LEN;
> +       }
> 
>         if (bp->caps & MACB_CAPS_BD_RD_PREFETCH) {
>                 val = GEM_BFEXT(RXBD_RDBUFF, gem_readl(bp, DCFG10));
> --
> 2.30.2
>