linux-toradex.git/net, branch v2.6.29.2 Linux kernel for Apalis and Colibri modules gso: Fix support for linear packets 2009-04-27T17:37:05+00:00 Herbert Xu herbert@gondor.apana.org.au 2009-04-21T11:31:50+00:00 d6af2381754182d727fb4682e785f56ae8508210 upstream commit: 2f181855a0b3c2b39314944add7b41c15647cf86 When GRO/frag_list support was added to GSO, I made an error which broke the support for segmenting linear GSO packets (GSO packets are normally non-linear in the payload). These days most of these packets are constructed by the tun driver, which prefers to allocate linear memory if possible. This is fixed in the latest kernel, but for 2.6.29 and earlier it is still the norm. Therefore this bug causes failures with GSO when used with tun in 2.6.29. Reported-by: James Huang <jamesclhuang@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 2f181855a0b3c2b39314944add7b41c15647cf86

When GRO/frag_list support was added to GSO, I made an error
which broke the support for segmenting linear GSO packets (GSO
packets are normally non-linear in the payload).

These days most of these packets are constructed by the tun
driver, which prefers to allocate linear memory if possible.
This is fixed in the latest kernel, but for 2.6.29 and earlier
it is still the norm.

Therefore this bug causes failures with GSO when used with tun
in 2.6.29.

Reported-by: James Huang <jamesclhuang@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
netfilter: {ip, ip6, arp}_tables: fix incorrect loop detection 2009-04-27T17:36:58+00:00 Patrick McHardy kaber@trash.net 2009-04-06T15:31:29+00:00 6bc1b5deb47f0fc3d697abd2fcd417618cf07e3f upstream commit: 1f9352ae2253a97b07b34dcf16ffa3b4ca12c558 Commit e1b4b9f ([NETFILTER]: {ip,ip6,arp}_tables: fix exponential worst-case search for loops) introduced a regression in the loop detection algorithm, causing sporadic incorrectly detected loops. When a chain has already been visited during the check, it is treated as having a standard target containing a RETURN verdict directly at the beginning in order to not check it again. The real target of the first rule is then incorrectly treated as STANDARD target and checked not to contain invalid verdicts. Fix by making sure the rule does actually contain a standard target. Based on patch by Francis Dupont <Francis_Dupont@isc.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 1f9352ae2253a97b07b34dcf16ffa3b4ca12c558

Commit e1b4b9f ([NETFILTER]: {ip,ip6,arp}_tables: fix exponential worst-case
search for loops) introduced a regression in the loop detection algorithm,
causing sporadic incorrectly detected loops.

When a chain has already been visited during the check, it is treated as
having a standard target containing a RETURN verdict directly at the
beginning in order to not check it again. The real target of the first
rule is then incorrectly treated as STANDARD target and checked not to
contain invalid verdicts.

Fix by making sure the rule does actually contain a standard target.

Based on patch by Francis Dupont <Francis_Dupont@isc.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
net/netrom: Fix socket locking 2009-04-27T17:36:57+00:00 Jean Delvare jdelvare@suse.de 2009-04-22T07:49:51+00:00 df5b6025d1a9e2e61dde1fd28257082751264c07 upstream commit: cc29c70dd581f85ee7a3e7980fb031f90b90a2ab Patch "af_rose/x25: Sanity check the maximum user frame size" (commit 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9) from Alan Cox got locking wrong. If we bail out due to user frame size being too large, we must unlock the socket beforehand. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: cc29c70dd581f85ee7a3e7980fb031f90b90a2ab

Patch "af_rose/x25: Sanity check the maximum user frame size"
(commit 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9) from Alan Cox got
locking wrong. If we bail out due to user frame size being too large,
we must unlock the socket beforehand.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
af_rose/x25: Sanity check the maximum user frame size 2009-04-27T17:36:57+00:00 Alan Cox alan@lxorguk.ukuu.org.uk 2009-03-27T07:28:21+00:00 33d06566b593703a972da232d08b6a12176f1854 upstream commit: 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9 CVE-2009-0795. Otherwise we can wrap the sizes and end up sending garbage. Closes #10423 Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9

CVE-2009-0795.

Otherwise we can wrap the sizes and end up sending garbage.

Closes #10423

Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
cfg80211: fix incorrect assumption on last_request for 11d 2009-04-02T20:55:19+00:00 Luis R. Rodriguez lrodriguez@atheros.com 2009-03-28T01:45:08+00:00 cbb76e6c205242d8889f9979d53f22a43328b9ec upstream commit: cc0b6fe88e99096868bdbacbf486c97299533b5a The incorrect assumption is the last regulatory request (last_request) is always a country IE when processing country IEs. Although this is true 99% of the time the first time this happens this could not be true. This fixes an oops in the branch check for the last_request when accessing drv_last_ie. The access was done under the assumption the struct won't be null. Note to stable: to port to 29 replace as follows, only 29 has country IE code: s|NL80211_REGDOM_SET_BY_COUNTRY_IE|REGDOM_SET_BY_COUNTRY_IE Cc: stable@kernel.org Reported-by: Quentin Armitage <Quentin@armitage.org.uk> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: cc0b6fe88e99096868bdbacbf486c97299533b5a

The incorrect assumption is the last regulatory request
(last_request) is always a country IE when processing
country IEs. Although this is true 99% of the time the
first time this happens this could not be true.

This fixes an oops in the branch check for the last_request
when accessing drv_last_ie. The access was done under the
assumption the struct won't be null.

Note to stable: to port to 29 replace as follows, only 29 has
country IE code:

s|NL80211_REGDOM_SET_BY_COUNTRY_IE|REGDOM_SET_BY_COUNTRY_IE

Cc: stable@kernel.org
Reported-by: Quentin Armitage <Quentin@armitage.org.uk>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[chrisw: backport to 2.6.29]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
cfg80211: force last_request to be set for OLD_REG if regdom is EU 2009-04-02T20:55:17+00:00 Luis R. Rodriguez lrodriguez@atheros.com 2009-03-28T01:45:10+00:00 0e8cb3e1ded5f5fa57f9bb40fe75d7c35ad70985 upstream commit: 2e097dc65673ed421bbc2e49f52c125aa43a8ee6 Although EU is a bogus alpha2 we need to process the send request as our code depends on last_request being set. Cc: stable@kernel.org Reported-by: Quentin Armitage <Quentin@armitage.org.uk> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org> Port-acked-by: Luis R. Rodriguez <lrodriguez@atheros.com> 
upstream commit: 2e097dc65673ed421bbc2e49f52c125aa43a8ee6

Although EU is a bogus alpha2 we need to process the send request
as our code depends on last_request being set.

Cc: stable@kernel.org
Reported-by: Quentin Armitage <Quentin@armitage.org.uk>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[chrisw: backport to 2.6.29]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Port-acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
xfrm: spin_lock() should be spin_unlock() in xfrm_state.c 2009-04-02T20:55:15+00:00 Chuck Ebbert cebbert@redhat.com 2009-03-27T07:22:01+00:00 ce2a2dc25260683d83a895bf11a2667aaac84feb [ Upstream commit 7d0b591c655ca0d72ebcbd242cf659a20a8995c5 ] spin_lock() should be spin_unlock() in xfrm_state_walk_done(). caused by: commit 12a169e7d8f4b1c95252d8b04ed0f1033ed7cfe2 "ipsec: Put dumpers on the dump list" Reported-by: Marc Milgram <mmilgram@redhat.com> Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
[ Upstream commit 7d0b591c655ca0d72ebcbd242cf659a20a8995c5 ]

spin_lock() should be spin_unlock() in xfrm_state_walk_done().

caused by:
commit 12a169e7d8f4b1c95252d8b04ed0f1033ed7cfe2
"ipsec: Put dumpers on the dump list"

Reported-by: Marc Milgram <mmilgram@redhat.com>
Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
ipv6: Plug sk_buff leak in ipv6_rcv (net/ipv6/ip6_input.c) 2009-04-02T20:55:15+00:00 Jesper Nilsson jesper.nilsson@axis.com 2009-03-27T07:17:45+00:00 c8289b1f3fb7ab89146a29e280c8f64d4f51f53a [ Upstream commit 71f6f6dfdf7c7a67462386d9ea05c1095a89c555 ] Commit 778d80be52699596bf70e0eb0761cf5e1e46088d (ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface) seems to have introduced a leak of sk_buff's for ipv6 traffic, at least in some configurations where idev is NULL, or when ipv6 is disabled via sysctl. The problem is that if the first condition of the if-statement returns non-NULL, it returns an skb with only one reference, and when the other conditions apply, execution jumps to the "out" label, which does not call kfree_skb for it. To plug this leak, change to use the "drop" label instead. (this relies on it being ok to call kfree_skb on NULL) This also allows us to avoid calling rcu_read_unlock here, and removes the only user of the "out" label. Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
[ Upstream commit 71f6f6dfdf7c7a67462386d9ea05c1095a89c555 ]

Commit 778d80be52699596bf70e0eb0761cf5e1e46088d
(ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface)
seems to have introduced a leak of sk_buff's for ipv6 traffic,
at least in some configurations where idev is NULL, or when ipv6
is disabled via sysctl.

The problem is that if the first condition of the if-statement
returns non-NULL, it returns an skb with only one reference,
and when the other conditions apply, execution jumps to the "out"
label, which does not call kfree_skb for it.

To plug this leak, change to use the "drop" label instead.
(this relies on it being ok to call kfree_skb on NULL)
This also allows us to avoid calling rcu_read_unlock here,
and removes the only user of the "out" label.

Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
GRO: Disable GRO on legacy netif_rx path 2009-04-02T20:55:15+00:00 Herbert Xu herbert@gondor.apana.org.au 2009-03-26T07:59:10+00:00 ed421a64825501e0bdfe848c9decf05d270a9adb [ Upstream commit 8f1ead2d1a626ed0c85b3d2c2046a49081d5933f ] When I fixed the GRO crash in the legacy receive path I used napi_complete to replace __napi_complete. Unfortunately they're not the same when NETPOLL is enabled, which may result in us not calling __napi_complete at all. What's more, we really do need to keep the __napi_complete call within the IRQ-off section since in theory an IRQ can occur in between and fill up the backlog to the maximum, causing us to lock up. Since we can't seem to find a fix that works properly right now, this patch reverts all the GRO support from the netif_rx path. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
[ Upstream commit 8f1ead2d1a626ed0c85b3d2c2046a49081d5933f ]

When I fixed the GRO crash in the legacy receive path I used
napi_complete to replace __napi_complete.  Unfortunately they're
not the same when NETPOLL is enabled, which may result in us
not calling __napi_complete at all.

What's more, we really do need to keep the __napi_complete call
within the IRQ-off section since in theory an IRQ can occur in
between and fill up the backlog to the maximum, causing us to
lock up.

Since we can't seem to find a fix that works properly right now,
this patch reverts all the GRO support from the netif_rx path.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
bridge: bad error handling when adding invalid ether address 2009-04-02T20:55:15+00:00 Stephen Hemminger shemminger@vyatta.com 2009-03-26T04:01:47+00:00 813352bc3317b1104212667ce227a901a8d49908 [ Upstream commit cda6d377ec6b2ee2e58d563d0bd7eb313e0165df ] This fixes an crash when empty bond device is added to a bridge. If an interface with invalid ethernet address (all zero) is added to a bridge, then bridge code detects it when setting up the forward databas entry. But the error unwind is broken, the bridge port object can get freed twice: once when ref count went to zeo, and once by kfree. Since object is never really accessible, just free it. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
[ Upstream commit cda6d377ec6b2ee2e58d563d0bd7eb313e0165df ]

This fixes an crash when empty bond device is added to a bridge.
If an interface with invalid ethernet address (all zero) is added
to a bridge, then bridge code detects it when setting up the forward
databas entry. But the error unwind is broken, the bridge port object
can get freed twice: once when ref count went to zeo, and once by kfree.
Since object is never really accessible, just free it.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>