netdev - Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type

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]

Message-ID: <87y55cf8yq.fsf@nemi.mork.no>
Date:	Tue, 29 Oct 2013 15:27:41 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Larry Finger <Larry.Finger@...inger.net>, <linville@...driver.com>,
	<linux-wireless@...r.kernel.org>,
	"Mark Cave-Ayland" <mark.cave-ayland@...nde.co.uk>,
	<netdev@...r.kernel.org>, Stable <stable@...r.kernel.org>
Subject: Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type

Ben Hutchings <bhutchings@...arflare.com> writes:

>> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>>  
>>  	ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
>>  			      SNAP_SIZE + PROTOC_TYPE_SIZE);
>> -	ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
>> -	/*	ether_type = ntohs(ether_type); */
>> +	ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
>> +					     SNAP_SIZE));
>>  
>>  	if (ETH_P_IP == ether_type) {
>>  		if (IPPROTO_UDP == ip->protocol) {
>
> This crazy function also says that *all* IPv6 frames are special, which
> apparently means that on TX they should get sent at the lowest possible
> bit rate.  So I think this is going to cause a regression for IPv6
> throughput unless you remove that case.
>
> The DHCP case is also not validating IP and UDP header lengths against
> the packet length, though this may be harmless in practice.

It's not validating the upper 8 bits of the port numbers either, so it
will hit random UDP traffic in addition to DHCP. 

But it was good to see this function now. I was wondering how to support
some buggy 3G modem firmware without ugly hacks. Seems there will always
be worse hacks in drivers/net, no matter what I do :-)


Bjørn
--
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