<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net, branch v3.19.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>udptunnels: Call handle_offloads after inserting vlan tag.</title>
<updated>2015-04-29T08:23:44+00:00</updated>
<author>
<name>Jesse Gross</name>
<email>jesse@nicira.com</email>
</author>
<published>2015-04-09T18:19:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=174fbb303fdd8f42486ae7efa2ce428708c28e06'/>
<id>174fbb303fdd8f42486ae7efa2ce428708c28e06</id>
<content type='text'>
[ Upstream commit b736a623bd099cdf5521ca9bd03559f3bc7fa31c ]

handle_offloads() calls skb_reset_inner_headers() to store
the layer pointers to the encapsulated packet. However, we
currently push the vlag tag (if there is one) onto the packet
afterwards. This changes the MAC header for the encapsulated
packet but it is not reflected in skb-&gt;inner_mac_header, which
breaks GSO and drivers which attempt to use this for encapsulation
offloads.

Fixes: 1eaa8178 ("vxlan: Add tx-vlan offload support.")
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b736a623bd099cdf5521ca9bd03559f3bc7fa31c ]

handle_offloads() calls skb_reset_inner_headers() to store
the layer pointers to the encapsulated packet. However, we
currently push the vlag tag (if there is one) onto the packet
afterwards. This changes the MAC header for the encapsulated
packet but it is not reflected in skb-&gt;inner_mac_header, which
breaks GSO and drivers which attempt to use this for encapsulation
offloads.

Fixes: 1eaa8178 ("vxlan: Add tx-vlan offload support.")
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>skbuff: Do not scrub skb mark within the same name space</title>
<updated>2015-04-29T08:23:43+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2015-04-16T01:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d385d003dc72f09d83b05030d27a53c0b2475e78'/>
<id>d385d003dc72f09d83b05030d27a53c0b2475e78</id>
<content type='text'>
[ Upstream commit 213dd74aee765d4e5f3f4b9607fef0cf97faa2af ]

On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote:
&gt; Le 15/04/2015 15:57, Herbert Xu a écrit :
&gt; &gt;On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
&gt; [snip]
&gt; &gt;Subject: skbuff: Do not scrub skb mark within the same name space
&gt; &gt;
&gt; &gt;The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
&gt; Maybe add a Fixes tag?
&gt; Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
&gt;
&gt; &gt;harmonize cleanup done on skb on rx path") broke anyone trying to
&gt; &gt;use netfilter marking across IPv4 tunnels.  While most of the
&gt; &gt;fields that are cleared by skb_scrub_packet don't matter, the
&gt; &gt;netfilter mark must be preserved.
&gt; &gt;
&gt; &gt;This patch rearranges skb_scurb_packet to preserve the mark field.
&gt; nit: s/scurb/scrub
&gt;
&gt; Else it's fine for me.

Sure.

PS I used the wrong email for James the first time around.  So
let me repeat the question here.  Should secmark be preserved
or cleared across tunnels within the same name space? In fact,
do our security models even support name spaces?

---8&lt;---
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
harmonize cleanup done on skb on rx path") broke anyone trying to
use netfilter marking across IPv4 tunnels.  While most of the
fields that are cleared by skb_scrub_packet don't matter, the
netfilter mark must be preserved.

This patch rearranges skb_scrub_packet to preserve the mark field.

Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 213dd74aee765d4e5f3f4b9607fef0cf97faa2af ]

On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote:
&gt; Le 15/04/2015 15:57, Herbert Xu a écrit :
&gt; &gt;On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
&gt; [snip]
&gt; &gt;Subject: skbuff: Do not scrub skb mark within the same name space
&gt; &gt;
&gt; &gt;The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
&gt; Maybe add a Fixes tag?
&gt; Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
&gt;
&gt; &gt;harmonize cleanup done on skb on rx path") broke anyone trying to
&gt; &gt;use netfilter marking across IPv4 tunnels.  While most of the
&gt; &gt;fields that are cleared by skb_scrub_packet don't matter, the
&gt; &gt;netfilter mark must be preserved.
&gt; &gt;
&gt; &gt;This patch rearranges skb_scurb_packet to preserve the mark field.
&gt; nit: s/scurb/scrub
&gt;
&gt; Else it's fine for me.

Sure.

PS I used the wrong email for James the first time around.  So
let me repeat the question here.  Should secmark be preserved
or cleared across tunnels within the same name space? In fact,
do our security models even support name spaces?

---8&lt;---
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
harmonize cleanup done on skb on rx path") broke anyone trying to
use netfilter marking across IPv4 tunnels.  While most of the
fields that are cleared by skb_scrub_packet don't matter, the
netfilter mark must be preserved.

This patch rearranges skb_scrub_packet to preserve the mark field.

Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "net: Reset secmark when scrubbing packet"</title>
<updated>2015-04-29T08:23:43+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2015-04-16T08:12:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5fe5245de99b6842fe4b22cc98fae6c2e95eebad'/>
<id>5fe5245de99b6842fe4b22cc98fae6c2e95eebad</id>
<content type='text'>
[ Upstream commit 4c0ee414e877b899f7fc80aafb98d9425c02797f ]

This patch reverts commit b8fb4e0648a2ab3734140342002f68fb0c7d1602
because the secmark must be preserved even when a packet crosses
namespace boundaries.  The reason is that security labels apply to
the system as a whole and is not per-namespace.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4c0ee414e877b899f7fc80aafb98d9425c02797f ]

This patch reverts commit b8fb4e0648a2ab3734140342002f68fb0c7d1602
because the secmark must be preserved even when a packet crosses
namespace boundaries.  The reason is that security labels apply to
the system as a whole and is not per-namespace.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: tcp_make_synack() should clear skb-&gt;tstamp</title>
<updated>2015-04-29T08:23:43+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-04-09T20:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b6c8d50c051e5cd96701c0c8067024a1046b75b'/>
<id>1b6c8d50c051e5cd96701c0c8067024a1046b75b</id>
<content type='text'>
[ Upstream commit b50edd7812852d989f2ef09dcfc729690f54a42d ]

I noticed tcpdump was giving funky timestamps for locally
generated SYNACK messages on loopback interface.

11:42:46.938990 IP 127.0.0.1.48245 &gt; 127.0.0.2.23850: S
945476042:945476042(0) win 43690 &lt;mss 65495,nop,nop,sackOK,nop,wscale 7&gt;

20:28:58.502209 IP 127.0.0.2.23850 &gt; 127.0.0.1.48245: S
3160535375:3160535375(0) ack 945476043 win 43690 &lt;mss
65495,nop,nop,sackOK,nop,wscale 7&gt;

This is because we need to clear skb-&gt;tstamp before
entering lower stack, otherwise net_timestamp_check()
does not set skb-&gt;tstamp.

Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)-&gt;when")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b50edd7812852d989f2ef09dcfc729690f54a42d ]

I noticed tcpdump was giving funky timestamps for locally
generated SYNACK messages on loopback interface.

11:42:46.938990 IP 127.0.0.1.48245 &gt; 127.0.0.2.23850: S
945476042:945476042(0) win 43690 &lt;mss 65495,nop,nop,sackOK,nop,wscale 7&gt;

20:28:58.502209 IP 127.0.0.2.23850 &gt; 127.0.0.1.48245: S
3160535375:3160535375(0) ack 945476043 win 43690 &lt;mss
65495,nop,nop,sackOK,nop,wscale 7&gt;

This is because we need to clear skb-&gt;tstamp before
entering lower stack, otherwise net_timestamp_check()
does not set skb-&gt;tstamp.

Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)-&gt;when")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: protect skb-&gt;sk accesses from recursive dereference inside the stack</title>
<updated>2015-04-29T08:23:42+00:00</updated>
<author>
<name>hannes@stressinduktion.org</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2015-04-01T15:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3fe207e4637a2e792c46a08666aa722f77d7f8f7'/>
<id>3fe207e4637a2e792c46a08666aa722f77d7f8f7</id>
<content type='text'>
[ Upstream commit f60e5990d9c1424af9dbca60a23ba2a1c7c1ce90 ]

We should not consult skb-&gt;sk for output decisions in xmit recursion
levels &gt; 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb-&gt;sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f60e5990d9c1424af9dbca60a23ba2a1c7c1ce90 ]

We should not consult skb-&gt;sk for output decisions in xmit recursion
levels &gt; 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb-&gt;sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: fix FRTO undo on cumulative ACK of SACKed range</title>
<updated>2015-04-29T08:23:42+00:00</updated>
<author>
<name>Neal Cardwell</name>
<email>ncardwell@google.com</email>
</author>
<published>2015-04-02T00:26:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84212e36d28eafcc936165417b8ac8684cfa1bd6'/>
<id>84212e36d28eafcc936165417b8ac8684cfa1bd6</id>
<content type='text'>
[ Upstream commit 666b805150efd62f05810ff0db08f44a2370c937 ]

On processing cumulative ACKs, the FRTO code was not checking the
SACKed bit, meaning that there could be a spurious FRTO undo on a
cumulative ACK of a previously SACKed skb.

The FRTO code should only consider a cumulative ACK to indicate that
an original/unretransmitted skb is newly ACKed if the skb was not yet
SACKed.

The effect of the spurious FRTO undo would typically be to make the
connection think that all previously-sent packets were in flight when
they really weren't, leading to a stall and an RTO.

Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 666b805150efd62f05810ff0db08f44a2370c937 ]

On processing cumulative ACKs, the FRTO code was not checking the
SACKed bit, meaning that there could be a spurious FRTO undo on a
cumulative ACK of a previously SACKed skb.

The FRTO code should only consider a cumulative ACK to indicate that
an original/unretransmitted skb is newly ACKed if the skb was not yet
SACKed.

The effect of the spurious FRTO undo would typically be to make the
connection think that all previously-sent packets were in flight when
they really weren't, leading to a stall and an RTO.

Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>openvswitch: Return vport module ref before destruction</title>
<updated>2015-04-29T08:23:42+00:00</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@suug.ch</email>
</author>
<published>2015-03-30T11:57:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=69ed02241c04c6a0515720d079ff49e420d4b2f8'/>
<id>69ed02241c04c6a0515720d079ff49e420d4b2f8</id>
<content type='text'>
[ Upstream commit fa2d8ff4e3522b4e05f590575d3eb8087f3a8cdc ]

Return module reference before invoking the respective vport
-&gt;destroy() function. This is needed as ovs_vport_del() is not
invoked inside an RCU read side critical section so the kfree
can occur immediately before returning to ovs_vport_del().

Returning the module reference before -&gt;destroy() is safe because
the module unregistration is blocked on ovs_lock which we hold
while destroying the datapath.

Fixes: 62b9c8d0372d ("ovs: Turn vports with dependencies into separate modules")
Reported-by: Pravin Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit fa2d8ff4e3522b4e05f590575d3eb8087f3a8cdc ]

Return module reference before invoking the respective vport
-&gt;destroy() function. This is needed as ovs_vport_del() is not
invoked inside an RCU read side critical section so the kfree
can occur immediately before returning to ovs_vport_del().

Returning the module reference before -&gt;destroy() is safe because
the module unregistration is blocked on ovs_lock which we hold
while destroying the datapath.

Fixes: 62b9c8d0372d ("ovs: Turn vports with dependencies into separate modules")
Reported-by: Pravin Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: tcp6: fix double call of tcp_v6_fill_cb()</title>
<updated>2015-04-29T08:23:41+00:00</updated>
<author>
<name>Alexey Kodanev</name>
<email>alexey.kodanev@oracle.com</email>
</author>
<published>2015-03-27T09:24:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1d069b5a314de8f2c9e598ca0794e358da84f223'/>
<id>1d069b5a314de8f2c9e598ca0794e358da84f223</id>
<content type='text'>
[ Upstream commit 4ad19de8774e2a7b075b3e8ea48db85adcf33fa6 ]

tcp_v6_fill_cb() will be called twice if socket's state changes from
TCP_TIME_WAIT to TCP_LISTEN. That can result in control buffer data
corruption because in the second tcp_v6_fill_cb() call it's not copying
IP6CB(skb) anymore, but 'seq', 'end_seq', etc., so we can get weird and
unpredictable results. Performance loss of up to 1200% has been observed
in LTP/vxlan03 test.

This can be fixed by copying inet6_skb_parm to the beginning of 'cb'
only if xfrm6_policy_check() and tcp_v6_fill_cb() are going to be
called again.

Fixes: 2dc49d1680b53 ("tcp6: don't move IP6CB before xfrm6_policy_check()")

Signed-off-by: Alexey Kodanev &lt;alexey.kodanev@oracle.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4ad19de8774e2a7b075b3e8ea48db85adcf33fa6 ]

tcp_v6_fill_cb() will be called twice if socket's state changes from
TCP_TIME_WAIT to TCP_LISTEN. That can result in control buffer data
corruption because in the second tcp_v6_fill_cb() call it's not copying
IP6CB(skb) anymore, but 'seq', 'end_seq', etc., so we can get weird and
unpredictable results. Performance loss of up to 1200% has been observed
in LTP/vxlan03 test.

This can be fixed by copying inet6_skb_parm to the beginning of 'cb'
only if xfrm6_policy_check() and tcp_v6_fill_cb() are going to be
called again.

Fixes: 2dc49d1680b53 ("tcp6: don't move IP6CB before xfrm6_policy_check()")

Signed-off-by: Alexey Kodanev &lt;alexey.kodanev@oracle.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: Don't reduce hop limit for an interface</title>
<updated>2015-04-29T08:23:41+00:00</updated>
<author>
<name>D.S. Ljungmark</name>
<email>ljungmark@modio.se</email>
</author>
<published>2015-03-25T08:28:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=553ecf745589a74d4195e6019a026c15b5048c58'/>
<id>553ecf745589a74d4195e6019a026c15b5048c58</id>
<content type='text'>
[ Upstream commit 6fd99094de2b83d1d4c8457f2c83483b2828e75a ]

A local route may have a lower hop_limit set than global routes do.

RFC 3756, Section 4.2.7, "Parameter Spoofing"

&gt;   1.  The attacker includes a Current Hop Limit of one or another small
&gt;       number which the attacker knows will cause legitimate packets to
&gt;       be dropped before they reach their destination.

&gt;   As an example, one possible approach to mitigate this threat is to
&gt;   ignore very small hop limits.  The nodes could implement a
&gt;   configurable minimum hop limit, and ignore attempts to set it below
&gt;   said limit.

Signed-off-by: D.S. Ljungmark &lt;ljungmark@modio.se&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6fd99094de2b83d1d4c8457f2c83483b2828e75a ]

A local route may have a lower hop_limit set than global routes do.

RFC 3756, Section 4.2.7, "Parameter Spoofing"

&gt;   1.  The attacker includes a Current Hop Limit of one or another small
&gt;       number which the attacker knows will cause legitimate packets to
&gt;       be dropped before they reach their destination.

&gt;   As an example, one possible approach to mitigate this threat is to
&gt;   ignore very small hop limits.  The nodes could implement a
&gt;   configurable minimum hop limit, and ignore attempts to set it below
&gt;   said limit.

Signed-off-by: D.S. Ljungmark &lt;ljungmark@modio.se&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: prevent fetching dst twice in early demux code</title>
<updated>2015-04-29T08:23:40+00:00</updated>
<author>
<name>Michal Kubeček</name>
<email>mkubecek@suse.cz</email>
</author>
<published>2015-03-23T14:14:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c3d7204d3d87c57294e639f27edf4454110d0426'/>
<id>c3d7204d3d87c57294e639f27edf4454110d0426</id>
<content type='text'>
[ Upstream commit d0c294c53a771ae7e84506dfbd8c18c30f078735 ]

On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux()

        struct dst_entry *dst = sk-&gt;sk_rx_dst;

        if (dst)
                dst = dst_check(dst, inet6_sk(sk)-&gt;rx_dst_cookie);

to code reading sk-&gt;sk_rx_dst twice, once for the test and once for
the argument of ip6_dst_check() (dst_check() is inline). This allows
ip6_dst_check() to be called with null first argument, causing a crash.

Protect sk-&gt;sk_rx_dst access by READ_ONCE() both in IPv4 and IPv6
TCP early demux code.

Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
Fixes: c7109986db3c ("ipv6: Early TCP socket demux")
Signed-off-by: Michal Kubecek &lt;mkubecek@suse.cz&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d0c294c53a771ae7e84506dfbd8c18c30f078735 ]

On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux()

        struct dst_entry *dst = sk-&gt;sk_rx_dst;

        if (dst)
                dst = dst_check(dst, inet6_sk(sk)-&gt;rx_dst_cookie);

to code reading sk-&gt;sk_rx_dst twice, once for the test and once for
the argument of ip6_dst_check() (dst_check() is inline). This allows
ip6_dst_check() to be called with null first argument, causing a crash.

Protect sk-&gt;sk_rx_dst access by READ_ONCE() both in IPv4 and IPv6
TCP early demux code.

Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
Fixes: c7109986db3c ("ipv6: Early TCP socket demux")
Signed-off-by: Michal Kubecek &lt;mkubecek@suse.cz&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
