Android t qpr1 beta 2 release 0.5
bcmdhd: HOST_SFH_LLC - unclone the skb in xmit handler if it is in cloned state
Problem:
In HOST_SFH_LLC feature the ethernet header in the skb->data is replaced with SFH+LLC header.
In android world, if an application applies a packet filter, then the kernel clones the skb and hands over the same to the filter.
Cloning of skb does not copy the skb->data area. So when the upper layer application reads the packet received from the packet filter
it may see a wrong ethernet address due to the HOST_SFH_LLC feature having replaced ethernet header with SFH+LLC.
Ex:- in adb bugreport, ARP request Tx is wrongly classified as ARP request Rx and the source mac address is shown as some invalid addr aa:aa:03:00:00:00
2021-06-16T10:49:19.744 - RX aa:aa:03:00:00:00 > 4a:8b:35:18:00:24 arp who-has 192.168.1.100
[4A8B35180024AAAA03000000080600010800060400018E914A8B3518C0A801658C1645CE7F5DC0A80164]
Solution:
As per GG kernel team [b/214957620]:
"To be clear: it is up to the *writer* to call skb_unclone() before writing to make sure they *own* the skb.
(or perhaps if this is some header only change, then something like skb_header_unclone(), skb_cow() or even skb_cow_head() maybe more appropriate - though I don't know the intricacies of using those interfaces: I'm sure netdev@vger mailing list could help, or you could look at other (wifi?) network drivers and what they do - this can't be a rare problem)"
Analysis:
Analysed other wireless drivers in the kernel code, and found that there too before any modification of cloned skb data, either skb copy or clone or equivalent operation is done.
ex:-
/drivers/net/wireless/intel/ipw2x00/libipw_tx.c - libipw_xmit()
net/mac80211/tx.c - ieee80211_xmit()
Fix:
Call skb_unclone on the skb in dhd_start_xmit() if skb_cloned for the skb returns true.
Bug: 214957620
Test: sanity test and performance test are passed.
Change-Id: Idc97e9c0c09b2fcf79c645bd56077309d899cd18
Signed-off-by: Sungjoon Park <sungjoon.park@broadcom.corp-partner.google.com>
1 file changed
