summaryrefslogtreecommitdiffstats
path: root/drivers/net/davinci_emac.c
diff options
context:
space:
mode:
authorBen McKeegan <ben@netservers.co.uk>2009-11-16 03:44:25 +0000
committerDavid S. Miller <davem@davemloft.net>2009-11-16 23:51:34 -0800
commit82b3cc1a2f5e46300a9dec4a8cc8106dc20a4c23 (patch)
tree1388b3a52e05a690a1084c06799fb934562901b2 /drivers/net/davinci_emac.c
parentc0e1f68bce454d244e2eea6b0ab7b3a217c673d2 (diff)
downloadtalos-obmc-linux-82b3cc1a2f5e46300a9dec4a8cc8106dc20a4c23.tar.gz
talos-obmc-linux-82b3cc1a2f5e46300a9dec4a8cc8106dc20a4c23.zip
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>
Diffstat (limited to 'drivers/net/davinci_emac.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud