netdev - Re: [PATCH] net: bnxt_en: Fix array overrun in bnxt_fill_l2_rewrite

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]

Date:   Mon, 11 Nov 2019 09:50:51 -0800
From:   Michael Chan <michael.chan@...adcom.com>
To:     Olof Johansson <olof@...om.net>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Venkat Duvvuru <venkatkumar.duvvuru@...adcom.com>,
        Netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: bnxt_en: Fix array overrun in bnxt_fill_l2_rewrite_fields()

On Sun, Nov 10, 2019 at 6:09 PM Olof Johansson <olof@...om.net> wrote:
>
> This is caused by what seems to be a fragile typing approach by
> the Broadcom firmware/driver:
>
> /* FW expects smac to be in u16 array format */
>
> So the driver uses eth_addr and eth_addr_mask as u16[6] instead of u8[12],
> so the math in bnxt_fill_l2_rewrite_fields does a [6] deref of the u16
> pointer, it goes out of bounds on the array.
>
> Just a few lines below, they use ETH_ALEN/2, so this must have been
> overlooked. I'm surprised original developers didn't notice the compiler
> warnings?!
>
> Fixes: 90f906243bf6 ("bnxt_en: Add support for L2 rewrite")
> Signed-off-by: Olof Johansson <olof@...om.net>
> ---
>  drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 25 ++++++++++++++-----------
>  1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
> index 174412a55e53c..cde2b81f6fe54 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
> @@ -149,29 +149,32 @@ static void bnxt_set_l2_key_mask(u32 part_key, u32 part_mask,
>
>  static int
>  bnxt_fill_l2_rewrite_fields(struct bnxt_tc_actions *actions,
> -                           u16 *eth_addr, u16 *eth_addr_mask)
> +                           u8 *eth_addr, u8 *eth_addr_mask)
>  {
>         u16 *p;
> +       u8 *am;
>         int j;
>
>         if (unlikely(bnxt_eth_addr_key_mask_invalid(eth_addr, eth_addr_mask)))
>                 return -EINVAL;
>
> -       if (!is_wildcard(&eth_addr_mask[0], ETH_ALEN)) {
> -               if (!is_exactmatch(&eth_addr_mask[0], ETH_ALEN))
> +       am = eth_addr_mask;
> +       if (!is_wildcard(am, ETH_ALEN)) {
> +               if (!is_exactmatch(am, ETH_ALEN))
>                         return -EINVAL;
>                 /* FW expects dmac to be in u16 array format */
> -               p = eth_addr;
> -               for (j = 0; j < 3; j++)
> +               p = (u16 *)am;

Wouldn't this cause unaligned access?  am may not be u16 aligned, right?

> +               for (j = 0; j < ETH_ALEN / 2; j++)
>                         actions->l2_rewrite_dmac[j] = cpu_to_be16(*(p + j));
>         }
>