netdev - Re: [PATCH] lan78xx: fix ip header misalignment

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

Date:   Mon, 21 Jan 2019 16:36:23 +0300
From:   "Yuriy M. Kaminskiy" <yumkam@...il.com>
To:     netdev@...r.kernel.org
Cc:     Oliver Neukum <oneukum@...e.com>
Subject: Re: [PATCH] lan78xx: fix ip header misalignment

On 21.01.2019 14:47, Yuriy M. Kaminskiy wrote:
> lan78xx.c:rx_submit() allocates space for frame-to-be-received with 
> netdev_alloc_skb_ip_align(), which misalign start of buffer by 2 bytes 
> in expectation that frame will start from 14-byte ethernet header, then 
> ip header; if start of buffer misaligned by 2 bytes, ip header will be 
> 16-byte aligned.
> 
> Unfortunately, usb frame that sent by lan78xx starts with another 
> 10-byte header (lan78xx_rx(): rx_cmd_a/rx_cmd_b/rx_cmd_c), *then* 
> follows ethernet header, and *then* ip header (which ends up being 
> misaligned).
> 
> This issue was noticed on arm platform (where misaligned 32-bit word 
> access triggers exception and leave traces in /proc/cpu/alignment, see
> https://github.com/raspberrypi/linux/issues/2599 ; for me, about any 
> ipv6 traffic that hits machine - `ping -I eth0 ip6-allnodes`, tcp/udp 
> packets, etc triggered increase in this counter, with 
> ip6_datagram_recv_common_ctl, icmpv6_echo_reply, etc as culprit).
> 
> If we just allocate skb data without any misalignment tricks, ip header 
> will end up and at offset 24 (8-byte aligned).
> 
> Patch attached; runtime-tested with raspbian fork of stable/4.14.y 
> [4.14.92] on Raspberry pi 3B+

I quickly reviewed other usbnet drivers for similar problems, it looks like:

1) ax88179_178a.c likely has similar problem (multiple packets in usb 
frame with 2-byte packet header, padded at end to 8-byte boundary; if 
first packet alignment will be fixed, it will fix all of them) and 
contains several potential read buffer overflows with misbehaving or 
malicious device.

2) cdc_eem.c likely has similar problem (usb frame contains several 
packets with 2-byte header), see eem_rx_fixup()

3) cx82310_eth.c  - ditto, see cx82310_rx_fixup()

4) dm9601.c - weird 3-byte header, affected, would need 7 bytes 
prepended to compensate, see dm9601_rx_fixup()

5) kalmia.c - likely affected, 6-byte header; no padding/alignment 
between packets, so 2nd and following packet may end up misaligned anyway.

6) lg-vl600.c - unsure; multi-packet frames, first packet probably fine, 
but no padding/alignment between packets, so 2nd and following packets 
may end up misaligned anyway.

7) net1080.c - something weird, probably affected.

8) pegasus.c - (not usbnet based) not sure, but `pegasus->chip == 
0x8513` seems affected (2-byte header prepended to ethernet frame), see 
read_bulk_callback()

9) rndis_host.c - unpredictable, packet offset is driven by device?

10) sierra_net.c - ditto

11) smsc75xx.c - 10-byte packet header, affected, padded to 4-bytes 
alignment at end;

12) smsc95xx.c [fixed in master]

13) sr9700.c - weird 3-byte packet header, multiply packets; no 
alignment between packets, so 2nd and following packet may end up 
misaligned anyway.

Given I have no access to hw, I won't try to compose patches for them 
(except for not-even-compile-tested patch to ax88179_178a.c as PoC).

P.S. I'm not subscribed, please CC me on reply.

View attachment "ax88179_178a.patch" of type "text/x-patch" (1925 bytes)