netdev - Re: [PATCH] ethernet: fm10k: Actually drop 4 bits

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]

Date:	Sat, 24 Jan 2015 00:18:59 +0000
From:	"Vick, Matthew" <matthew.vick@...el.com>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Alexander Duyck <alexander.h.duyck@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ethernet: fm10k: Actually drop 4 bits

On 1/22/15, 2:53 PM, "Rasmus Villemoes" <linux@...musvillemoes.dk> wrote:

>The comment explains the intention, but vid has type u16. Before the
>inner shift, it is promoted to int, which has plenty of space for all
>vid's bits, so nothing is dropped. Use a simple mask instead.
>
>Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
>---
> drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
>b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
>index 275423d4f777..b1c57d0166a9 100644
>--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
>+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
>@@ -335,7 +335,7 @@ static s32 fm10k_update_xc_addr_pf(struct fm10k_hw
>*hw, u16 glort,
> 		return FM10K_ERR_PARAM;
> 
> 	/* drop upper 4 bits of VLAN ID */
>-	vid = (vid << 4) >> 4;
>+	vid &= 0x0fff;
> 
> 	/* record fields */
> 	mac_update.mac_lower = cpu_to_le32(((u32)mac[2] << 24) |

Good catch! I noticed this too and was getting a patch together to address
this.

The difference is that I was planning on not silently accepting an invalid
VLAN ID to begin with and returning FM10K_ERR_PARAM if the VLAN was
invalid, which I think is a better approach for this situation. If it's
alright with you, I'll generate the patch shortly and credit you via your
Reported-by.

Cheers,
Matthew

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html