linux-stable.git/net/core/skbuff.c, branch v3.16

net: fix setting csum_start in skb_segment()

2014-06-26T03:45:54+00:00

Dave Jones reported that a crash is occurring in

csum_partial
tcp_gso_segment
inet_gso_segment
? update_dl_migration
skb_mac_gso_segment
__skb_gso_segment
dev_hard_start_xmit
sch_direct_xmit
__dev_queue_xmit
? dev_hard_start_xmit
dev_queue_xmit
ip_finish_output
? ip_output
ip_output
ip_forward_finish
ip_forward
ip_rcv_finish
ip_rcv
__netif_receive_skb_core
? __netif_receive_skb_core
? trace_hardirqs_on
__netif_receive_skb
netif_receive_skb_internal
napi_gro_complete
? napi_gro_complete
dev_gro_receive
? dev_gro_receive
napi_gro_receive

It looks like a likely culprit is that SKB_GSO_CB()->csum_start is
not set correctly when doing non-scatter gather. We are using
offset as opposed to doffset.

Reported-by: Dave Jones 
Tested-by: Dave Jones 
Signed-off-by: Tom Herbert 
Signed-off-by: Eric Dumazet 
Fixes: 7e2b10c1e52ca ("net: Support for multiple checksums with gso")
Acked-by: Tom Herbert 
Signed-off-by: David S. Miller

net: Fix save software checksum complete

2014-06-15T08:00:49+00:00

Geert reported issues regarding checksum complete and UDP.
The logic introduced in commit 7e3cead5172927732f51fde
("net: Save software checksum complete") is not correct.

This patch:
1) Restores code in __skb_checksum_complete_header except for setting
   CHECKSUM_UNNECESSARY. This function may be calculating checksum on
   something less than skb->len.
2) Adds saving checksum to __skb_checksum_complete. The full packet
   checksum 0..skb->len is calculated without adding in pseudo header.
   This value is saved in skb->csum and then the pseudo header is added
   to that to derive the checksum for validation.
3) In both __skb_checksum_complete_header and __skb_checksum_complete,
   set skb->csum_valid to whether checksum of zero was computed. This
   allows skb_csum_unnecessary to return true without changing to
   CHECKSUM_UNNECESSARY which was done previously.
4) Copy new csum related bits in __copy_skb_header.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Tom Herbert 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2014-06-11T23:02:55+00:00

Conflicts:
	net/core/rtnetlink.c
	net/core/skbuff.c

Both conflicts were very simple overlapping changes.

Signed-off-by: David S. Miller

net: add __pskb_copy_fclone and pskb_copy_for_clone

2014-06-11T22:38:02+00:00

There are several instances where a pskb_copy or __pskb_copy is
immediately followed by an skb_clone.

Add a couple of new functions to allow the copy skb to be allocated
from the fclone cache and thus speed up subsequent skb_clone calls.

Cc: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: Marek Lindner 
Cc: Simon Wunderlich 
Cc: Antonio Quartulli 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: Arvid Brodin 
Cc: Patrick McHardy 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Lauro Ramos Venancio 
Cc: Aloisio Almeida Jr 
Cc: Samuel Ortiz 
Cc: Jon Maloy 
Cc: Allan Stephens 
Cc: Andrew Hendry 
Cc: Eric Dumazet 
Reviewed-by: Christoph Paasch 
Signed-off-by: Octavian Purdila 
Signed-off-by: David S. Miller

net: fix UDP tunnel GSO of frag_list GRO packets

2014-06-11T07:48:47+00:00

This patch fixes a kernel BUG_ON in skb_segment. It is hit when
testing two VMs on openvswitch with one VM acting as VXLAN gateway.

During VXLAN packet GSO, skb_segment is called with skb->data
pointing to inner TCP payload. skb_segment calls skb_network_protocol
to retrieve the inner protocol. skb_network_protocol actually expects
skb->data to point to MAC and it calls pskb_may_pull with ETH_HLEN.
This ends up pulling in ETH_HLEN data from header tail. As a result,
pskb_trim logic is skipped and BUG_ON is hit later.

Move skb_push in front of skb_network_protocol so that skb->data
lines up properly.

kernel BUG at net/core/skbuff.c:2999!
Call Trace:
[] tcp_gso_segment+0x122/0x410
[] inet_gso_segment+0x13c/0x390
[] skb_mac_gso_segment+0x9b/0x170
[] skb_udp_tunnel_segment+0xd8/0x390
[] udp4_ufo_fragment+0x120/0x140
[] inet_gso_segment+0x13c/0x390
[] ? default_wake_function+0x12/0x20
[] skb_mac_gso_segment+0x9b/0x170
[] __skb_gso_segment+0x60/0xc0
[] dev_hard_start_xmit+0x183/0x550
[] sch_direct_xmit+0xfe/0x1d0
[] __dev_queue_xmit+0x214/0x4f0
[] dev_queue_xmit+0x10/0x20
[] ip_finish_output+0x66b/0x890
[] ip_output+0x58/0x90
[] ? fib_table_lookup+0x29f/0x350
[] ip_local_out_sk+0x39/0x50
[] iptunnel_xmit+0x10d/0x130
[] vxlan_xmit_skb+0x1d0/0x330 [vxlan]
[] vxlan_tnl_send+0x129/0x1a0 [openvswitch]
[] ovs_vport_send+0x26/0xa0 [openvswitch]
[] do_output+0x2e/0x50 [openvswitch]

Signed-off-by: Wei-Chun Chao 
Signed-off-by: David S. Miller

net: Support for multiple checksums with gso

2014-06-05T05:46:38+00:00

When creating a GSO packet segment we may need to set more than
one checksum in the packet (for instance a TCP checksum and
UDP checksum for VXLAN encapsulation). To be efficient, we want
to do checksum calculation for any part of the packet at most once.

This patch adds csum_start offset to skb_gso_cb. This tracks the
starting offset for skb->csum which is initially set in skb_segment.
When a protocol needs to compute a transport checksum it calls
gso_make_checksum which computes the checksum value from the start
of transport header to csum_start and then adds in skb->csum to get
the full checksum. skb->csum and csum_start are then updated to reflect
the checksum of the resultant packet starting from the transport header.

This patch also adds a flag to skbuff, encap_hdr_csum, which is set
in *gso_segment fucntions to indicate that a tunnel protocol needs
checksum calculation

Signed-off-by: Tom Herbert 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2014-05-24T04:32:30+00:00

Conflicts:
	drivers/net/bonding/bond_alb.c
	drivers/net/ethernet/altera/altera_msgdma.c
	drivers/net/ethernet/altera/altera_sgdma.c
	net/ipv6/xfrm6_output.c

Several cases of overlapping changes.

The xfrm6_output.c has a bug fix which overlaps the renaming
of skb->local_df to skb->ignore_df.

In the Altera TSE driver cases, the register access cleanups
in net-next overlapped with bug fixes done in net.

Similarly a bug fix to send ALB packets in the bonding driver using
the right source address overlaps with cleanups in net-next.

Signed-off-by: David S. Miller

net: gro: make sure skb->cb[] initial content has not to be zero

2014-05-16T21:24:54+00:00

Starting from linux-3.13, GRO attempts to build full size skbs.

Problem is the commit assumed one particular field in skb->cb[]
was clean, but it is not the case on some stacked devices.

Timo reported a crash in case traffic is decrypted before
reaching a GRE device.

Fix this by initializing NAPI_GRO_CB(skb)->last at the right place,
this also removes one conditional.

Thanks a lot to Timo for providing full reports and bisecting this.

Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb")
Bisected-by: Timo Teras 
Signed-off-by: Eric Dumazet 
Tested-by: Timo Teräs 
Signed-off-by: David S. Miller

net: rename local_df to ignore_df

2014-05-12T18:03:41+00:00

As suggested by several people, rename local_df to ignore_df,
since it means "ignore df bit if it is set".

Cc: Maciej Żenczykowski 
Cc: Florian Westphal 
Cc: David S. Miller 
Cc: Eric Dumazet 
Signed-off-by: Cong Wang 
Acked-by: Maciej Żenczykowski 
Signed-off-by: David S. Miller

net: Fix use after free by removing length arg from sk_data_ready callbacks.

2014-04-11T20:15:36+00:00

Several spots in the kernel perform a sequence like:

	skb_queue_tail(&sk->s_receive_queue, skb);
	sk->sk_data_ready(sk, skb->len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb->len access is potentially
to freed up memory.

Furthermore, the skb->len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller