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 <[email protected]>
---
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(ð_addr_mask[0], ETH_ALEN)) {
- if (!is_exactmatch(ð_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;
+ for (j = 0; j < ETH_ALEN / 2; j++)
actions->l2_rewrite_dmac[j] = cpu_to_be16(*(p + j));
}
- if (!is_wildcard(ð_addr_mask[ETH_ALEN], ETH_ALEN)) {
- if (!is_exactmatch(ð_addr_mask[ETH_ALEN], ETH_ALEN))
+ am = eth_addr_mask + ETH_ALEN;
+ if (!is_wildcard(am, ETH_ALEN)) {
+ if (!is_exactmatch(am, ETH_ALEN))
return -EINVAL;
/* FW expects smac to be in u16 array format */
- p = ð_addr[ETH_ALEN / 2];
- for (j = 0; j < 3; j++)
+ p = (u16 *)am;
+ for (j = 0; j < ETH_ALEN / 2; j++)
actions->l2_rewrite_smac[j] = cpu_to_be16(*(p + j));
}
@@ -285,12 +288,12 @@ static int bnxt_tc_parse_actions(struct bnxt *bp,
* smac (6 bytes) if rewrite of both is specified, otherwise either
* dmac or smac
*/
- u16 eth_addr_mask[ETH_ALEN] = { 0 };
+ u8 eth_addr_mask[ETH_ALEN * 2] = { 0 };
/* Used to store the L2 rewrite key for dmac (6 bytes) followed by
* smac (6 bytes) if rewrite of both is specified, otherwise either
* dmac or smac
*/
- u16 eth_addr[ETH_ALEN] = { 0 };
+ u8 eth_addr[ETH_ALEN * 2] = { 0 };
struct flow_action_entry *act;
int i, rc;
--
2.11.0
On Sun, Nov 10, 2019 at 06:08:55PM -0800, Olof Johansson 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 <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
On Sun, Nov 10, 2019 at 6:09 PM Olof Johansson <[email protected]> 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 <[email protected]>
> ---
> 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(ð_addr_mask[0], ETH_ALEN)) {
> - if (!is_exactmatch(ð_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));
> }
>