forked from luck/tmp_suning_uos_patched
ppp: fix BUG on non-linear SKB (multilink receive)
PPP does not correctly call pskb_may_pull() on all necessary receive paths before reading the PPP protocol, thus causing PPP to report seemingly random 'unsupported protocols' and eventually trigger BUG_ON(skb->len < skb->data_len) in skb_pull_rcsum() when receiving multilink protocol in non-linear skbs. ppp_receive_nonmp_frame() does not call pskb_may_pull() before reading the protocol number. For the non-mp receive path this is not a problem, as this check is done in ppp_receive_frame(). For the mp receive path, ppp_mp_reconstruct() usually copies the data into a new linear skb. However, in the case where the frame is made up of a single mp fragment, the mp header is pulled and the existing skb used. This skb was then passed to ppp_receive_nonmp_frame() without checking if the encapsulated protocol header could safely be read. Signed-off-by: Ben McKeegan <ben@netservers.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
c0e1f68bce
commit
82b3cc1a2f
|
@ -1944,8 +1944,15 @@ ppp_receive_mp_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)
|
|||
}
|
||||
|
||||
/* Pull completed packets off the queue and receive them. */
|
||||
while ((skb = ppp_mp_reconstruct(ppp)))
|
||||
ppp_receive_nonmp_frame(ppp, skb);
|
||||
while ((skb = ppp_mp_reconstruct(ppp))) {
|
||||
if (pskb_may_pull(skb, 2))
|
||||
ppp_receive_nonmp_frame(ppp, skb);
|
||||
else {
|
||||
++ppp->dev->stats.rx_length_errors;
|
||||
kfree_skb(skb);
|
||||
ppp_receive_error(ppp);
|
||||
}
|
||||
}
|
||||
|
||||
return;
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user