netdev - re: mlx4_en: fix endianness with blue frame support

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

Date:	Tue, 18 Sep 2012 10:34:48 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	cascardo@...ux.vnet.ibm.com
Cc:	netdev@...r.kernel.org
Subject: re: mlx4_en: fix endianness with blue frame support

Hello Thadeu Lima de Souza Cascardo,

The patch c5d6136e10d6: "mlx4_en: fix endianness with blue frame 
support" from Oct 10, 2011, leads to the following warning:
drivers/net/ethernet/mellanox/mlx4/en_tx.c:720 mlx4_en_xmit()
	 warn: potential memory corrupting cast. 4 vs 2 bytes

That patch introduced a call to cpu_to_be32() and added some endian
notation.

	*(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);

But it doesn't make sense because the data type is declared as u16 in
the header and we would be corrupting the next elements in the struct
which are ins_vlan and fence_size.

struct mlx4_wqe_ctrl_seg {
        __be32                  owner_opcode;
        __be16                  vlan_tag;
        u8                      ins_vlan;
        u8                      fence_size;

I guess the reason we get away with it is that the ->doorbell_qpn is
normally less that 65k. But doorbell_qpn is a u32 type so I think there
is a risk here.

regards,
dan carpenter

--
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