linux-toradex.git/net, branch v2.6.38.5

ip: ip_options_compile() resilient to NULL skb route

2011-04-21T21:33:00+00:00

commit c65353daf137dd41f3ede3baf62d561fca076228 upstream.

Scot Doyle demonstrated ip_options_compile() could be called with an skb
without an attached route, using a setup involving a bridge, netfilter,
and forged IP packets.

Let's make ip_options_compile() and ip_options_rcv_srr() a bit more
robust, instead of changing bridge/netfilter code.

With help from Hiroaki SHIMODA.

Reported-by: Scot Doyle 
Tested-by: Scot Doyle 
Signed-off-by: Eric Dumazet 
Cc: Stephen Hemminger 
Acked-by: Hiroaki SHIMODA 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: reset IPCB in br_parse_ip_options

2011-04-21T21:33:00+00:00

commit f8e9881c2aef1e982e5abc25c046820cd0b7cf64 upstream.

Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP
stack), missed one IPCB init before calling ip_options_compile()

Thanks to Scot Doyle for his tests and bug reports.

Reported-by: Scot Doyle 
Signed-off-by: Eric Dumazet 
Cc: Hiroaki SHIMODA 
Acked-by: Bandan Das 
Acked-by: Stephen Hemminger 
Cc: Jan Lübbe 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix HCI_RESET command synchronization

2011-04-21T21:32:59+00:00

commit f630cf0d5434e3923e1b8226ffa2753ead6b0ce5 upstream.

We can't send new commands before a cmd_complete for the HCI_RESET command
shows up.

Reported-by: Mikko Vinni 
Reported-by: Justin P. Mattock 
Reported-by: Ed Tomlinson 
Signed-off-by: Gustavo F. Padovan 
Tested-by: Justin P. Mattock 
Tested-by: Mikko Vinni 
Tested-by: Ed Tomlinson

bridge: Reset IPCB when entering IP stack on NF_FORWARD

2011-04-21T21:32:37+00:00

[ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ]

Whenever we enter the IP stack proper from bridge netfilter we
need to ensure that the skb is in a form the IP stack expects
it to be in.

The entry point on NF_FORWARD did not meet the requirements of
the IP stack, therefore leading to potential crashes/panics.

This patch fixes the problem.

Signed-off-by: Herbert Xu 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vlan: should take into account needed_headroom

2011-04-21T21:32:36+00:00

[ Upstream commit d870bfb9d366c5d466c0f5419a4ec95a3f71ea8a ]

Commit c95b819ad7 (gre: Use needed_headroom)
made gre use needed_headroom instead of hard_header_len

This uncover a bug in vlan code.

We should make sure vlan devices take into account their
real_dev->needed_headroom or we risk a crash in ipgre_header(), because
we dont have enough room to push IP header in skb.

Reported-by: Diddi Oscarsson 
Signed-off-by: Eric Dumazet 
Cc: Patrick McHardy 
Cc: Herbert Xu 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xfrm: Refcount destination entry on xfrm_lookup

2011-04-21T21:32:34+00:00

[ Upstream commit fbd5060875d25f7764fd1c3d35b83a8ed1d88d7b ]

We return a destination entry without refcount if a socket
policy is found in xfrm_lookup. This triggers a warning on
a negative refcount when freeeing this dst entry. So take
a refcount in this case to fix it.

This refcount was forgotten when xfrm changed to cache bundles
instead of policies for outgoing flows.

Signed-off-by: Steffen Klassert 
Acked-by: Timo Teräs 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: avoid cwnd moderation in undo

2011-04-21T21:32:33+00:00

[ Upstream commit 67d4120a1793138bc9f4a6eb61d0fc5298ed97e0 ]

In the current undo logic, cwnd is moderated after it was restored
to the value prior entering fast-recovery. It was moderated first
in tcp_try_undo_recovery then again in tcp_complete_cwr.

Since the undo indicates recovery was false, these moderations
are not necessary. If the undo is triggered when most of the
outstanding data have been acknowledged, the (restored) cwnd is
falsely pulled down to a small value.

This patch removes these cwnd moderations if cwnd is undone
  a) during fast-recovery
	b) by receiving DSACKs past fast-recovery

Signed-off-by: Yuchung Cheng 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: Pass __GFP_NOWARN to hash table allocation attempts.

2011-04-21T21:32:29+00:00

[ Upstream commit a84b50ceb7d640437d0dc28a2bef0d0de054de89 ]

Like DCCP and other similar pieces of code, there are mechanisms
here to try allocating smaller hash tables if the allocation
fails.  So pass in __GFP_NOWARN like the others do instead of
emitting a scary message.

Reported-by: Dave Jones 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net_sched: fix ip_tos2prio

2011-04-21T21:32:28+00:00

[ Upstream commit 4a2b9c3756077c05dd8666e458a751d2248b61b6 ]

ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
(1) instead of TC_PRIO_BESTEFFORT (0)

This means ECN enabled flows are placed in pfifo_fast/prio low priority
band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
probabilities.

This is rather unfortunate, given we would like ECN being more widely
used.

Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/

Signed-off-by: Dan Siemon 
Signed-off-by: Eric Dumazet 
Cc: Dave Täht 
Cc: Jonathan Morton 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.

2011-04-21T21:32:27+00:00

[ Upstream commit 9d2a8fa96a44ba242de3a6f56acaef7a40a97b97 ]

When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
by adding a mount point it appears I missed a critical ordering issue, in the
ipv6 initialization.  I had not realized that ipv6_sysctl_register is called
at the very end of the ipv6 initialization and in particular after we call
neigh_sysctl_register from ndisc_init.

"neigh" needs to be initialized in ipv6_static_sysctl_register which is
the first ipv6 table to initialized, and definitely before ndisc_init.
This removes the weirdness of duplicate tables while still providing a
"neigh" mount point which prevents races in sysctl unregistering.

This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
Reported-by: sunkan@zappa.cx
Signed-off-by: Eric W. Biederman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman