<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.15</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.15</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.15'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-06-03T00:49:45Z</updated>
<entry>
<title>net: filter: fix possible memory leak in __sk_prepare_filter()</title>
<updated>2014-06-03T00:49:45Z</updated>
<author>
<name>Leon Yu</name>
<email>chianglungyu@gmail.com</email>
</author>
<published>2014-06-01T05:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=418c96ac151a16a5094a95d14252c92c1d47ec67'/>
<id>urn:sha1:418c96ac151a16a5094a95d14252c92c1d47ec67</id>
<content type='text'>
__sk_prepare_filter() was reworked in commit bd4cf0ed3 (net: filter:
rework/optimize internal BPF interpreter's instruction set) so that it should
have uncharged memory once things went wrong. However that work isn't complete.
Error is handled only in __sk_migrate_filter() while memory can still leak in
the error path right after sk_chk_filter().

Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set")
Signed-off-by: Leon Yu &lt;chianglungyu@gmail.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Tested-by: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: fix cwnd undo on DSACK in F-RTO</title>
<updated>2014-06-02T23:50:49Z</updated>
<author>
<name>Yuchung Cheng</name>
<email>ycheng@google.com</email>
</author>
<published>2014-05-30T22:25:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0cfa5c07d6d1d7f8e710fc671c5ba1ce85e09fa4'/>
<id>urn:sha1:0cfa5c07d6d1d7f8e710fc671c5ba1ce85e09fa4</id>
<content type='text'>
This bug is discovered by an recent F-RTO issue on tcpm list
https://www.ietf.org/mail-archive/web/tcpm/current/msg08794.html

The bug is that currently F-RTO does not use DSACK to undo cwnd in
certain cases: upon receiving an ACK after the RTO retransmission in
F-RTO, and the ACK has DSACK indicating the retransmission is spurious,
the sender only calls tcp_try_undo_loss() if some never retransmisted
data is sacked (FLAG_ORIG_DATA_SACKED).

The correct behavior is to unconditionally call tcp_try_undo_loss so
the DSACK information is used properly to undo the cwnd reduction.

Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>netlink: Only check file credentials for implicit destinations</title>
<updated>2014-06-02T23:34:09Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-05-30T18:04:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2d7a85f4b06e9c27ff629f07a524c48074f07f81'/>
<id>urn:sha1:2d7a85f4b06e9c27ff629f07a524c48074f07f81</id>
<content type='text'>
It was possible to get a setuid root or setcap executable to write to
it's stdout or stderr (which has been set made a netlink socket) and
inadvertently reconfigure the networking stack.

To prevent this we check that both the creator of the socket and
the currentl applications has permission to reconfigure the network
stack.

Unfortunately this breaks Zebra which always uses sendto/sendmsg
and creates it's socket without any privileges.

To keep Zebra working don't bother checking if the creator of the
socket has privilege when a destination address is specified.  Instead
rely exclusively on the privileges of the sender of the socket.

Note from Andy: This is exactly Eric's code except for some comment
clarifications and formatting fixes.  Neither I nor, I think, anyone
else is thrilled with this approach, but I'm hesitant to wait on a
better fix since 3.15 is almost here.

Note to stable maintainers: This is a mess.  An earlier series of
patches in 3.15 fix a rather serious security issue (CVE-2014-0181),
but they did so in a way that breaks Zebra.  The offending series
includes:

    commit aa4cf9452f469f16cea8c96283b641b4576d4a7b
    Author: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
    Date:   Wed Apr 23 14:28:03 2014 -0700

        net: Add variants of capable for use on netlink messages

If a given kernel version is missing that series of fixes, it's
probably worth backporting it and this patch.  if that series is
present, then this fix is critical if you care about Zebra.

Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: fix inet_getid() and ipv6_select_ident() bugs</title>
<updated>2014-06-02T21:09:28Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-05-29T15:45:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=39c36094d78c39e038c1e499b2364e13bce36f54'/>
<id>urn:sha1:39c36094d78c39e038c1e499b2364e13bce36f54</id>
<content type='text'>
I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer-&gt;ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>bridge: Prevent insertion of FDB entry with disallowed vlan</title>
<updated>2014-06-02T20:38:23Z</updated>
<author>
<name>Toshiaki Makita</name>
<email>makita.toshiaki@lab.ntt.co.jp</email>
</author>
<published>2014-05-26T06:15:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e0d7968ab6c8bce2437b36fa7f04117e333f196d'/>
<id>urn:sha1:e0d7968ab6c8bce2437b36fa7f04117e333f196d</id>
<content type='text'>
br_handle_local_finish() is allowing us to insert an FDB entry with
disallowed vlan. For example, when port 1 and 2 are communicating in
vlan 10, and even if vlan 10 is disallowed on port 3, port 3 can
interfere with their communication by spoofed src mac address with
vlan id 10.

Note: Even if it is judged that a frame should not be learned, it should
not be dropped because it is destined for not forwarding layer but higher
layer. See IEEE 802.1Q-2011 8.13.10.

Signed-off-by: Toshiaki Makita &lt;makita.toshiaki@lab.ntt.co.jp&gt;
Acked-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>bridge: notify user space after fdb update</title>
<updated>2014-06-02T05:14:50Z</updated>
<author>
<name>Jon Maxwell</name>
<email>jmaxwell37@gmail.com</email>
</author>
<published>2014-05-29T07:27:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c65c7a306610ee7c13669a8f5601b472c19dc6f1'/>
<id>urn:sha1:c65c7a306610ee7c13669a8f5601b472c19dc6f1</id>
<content type='text'>
There has been a number incidents recently where customers running KVM have
reported that VM hosts on different Hypervisors are unreachable. Based on
pcap traces we found that the bridge was broadcasting the ARP request out
onto the network. However some NICs have an inbuilt switch which on occasions
were broadcasting the VMs ARP request back through the physical NIC on the
Hypervisor. This resulted in the bridge changing ports and incorrectly learning
that the VMs mac address was external. As a result the ARP reply was directed
back onto the external network and VM never updated it's ARP cache. This patch
will notify the bridge command, after a fdb has been updated to identify such
port toggling.

Signed-off-by: Jon Maxwell &lt;jmaxwell37@gmail.com&gt;
Reviewed-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Acked-by: Toshiaki Makita &lt;makita.toshiaki@lab.ntt.co.jp&gt;
Acked-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: fix wrong mac_len calculation for vlans</title>
<updated>2014-06-02T02:39:13Z</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@redhat.com</email>
</author>
<published>2014-05-28T16:03:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4b9b1cdf83c4facba89e0646aeac8ead679851b8'/>
<id>urn:sha1:4b9b1cdf83c4facba89e0646aeac8ead679851b8</id>
<content type='text'>
After 1e785f48d29a ("net: Start with correct mac_len in
skb_network_protocol") skb-&gt;mac_len is used as a start of the
calculation in skb_network_protocol() but that is not always correct. If
skb-&gt;protocol == 8021Q/AD, usually the vlan header is already inserted
in the skb (i.e. vlan reorder hdr == 0). Usually when the packet enters
dev_hard_xmit it has mac_len == 0 so we take 2 bytes from the
destination mac address (skb-&gt;data + VLAN_HLEN) as a type in
skb_network_protocol() and return vlan_depth == 4. In the case where TSO is
off, then the mac_len is set but it's == 18 (ETH_HLEN + VLAN_HLEN), so
skb_network_protocol() returns a type from inside the packet and
offset == 22. Also make vlan_depth unsigned as suggested before.
As suggested by Eric Dumazet, move the while() loop in the if() so we
can avoid additional testing in fast path.

Here are few netperf tests + debug printk's to illustrate:
cat netperf.tso-on.reorder-on.bugged
- Vlan -&gt; device (reorder on, default, this case is okay)
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.3.1 () port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.00    7111.54
[   81.605435] skb-&gt;len 65226 skb-&gt;gso_size 1448 skb-&gt;proto 0x800
skb-&gt;mac_len 0 vlan_depth 0 type 0x800

- Vlan -&gt; device (reorder off, bad)
cat netperf.tso-on.reorder-off.bugged
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.3.1 () port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.00     241.35
[  204.578332] skb-&gt;len 1518 skb-&gt;gso_size 0 skb-&gt;proto 0x8100
skb-&gt;mac_len 0 vlan_depth 4 type 0x5301
0x5301 are the last two bytes of the destination mac.

And if we stop TSO, we may get even the following:
[   83.343156] skb-&gt;len 2966 skb-&gt;gso_size 1448 skb-&gt;proto 0x8100
skb-&gt;mac_len 18 vlan_depth 22 type 0xb84
Because mac_len already accounts for VLAN_HLEN.

After the fix:
cat netperf.tso-on.reorder-off.fixed
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.3.1 () port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.01    5001.46
[   81.888489] skb-&gt;len 65230 skb-&gt;gso_size 1448 skb-&gt;proto 0x8100
skb-&gt;mac_len 0 vlan_depth 18 type 0x800

CC: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
CC: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
CC: Daniel Borkman &lt;dborkman@redhat.com&gt;
CC: David S. Miller &lt;davem@davemloft.net&gt;

Fixes:1e785f48d29a ("net: Start with correct mac_len in
skb_network_protocol")
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge</title>
<updated>2014-06-01T03:01:47Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-06-01T03:01:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6ce995c6f466e59a5f16e6eae8b265c1d13bb202'/>
<id>urn:sha1:6ce995c6f466e59a5f16e6eae8b265c1d13bb202</id>
<content type='text'>
Included changes:
- prevent NULL dereference in multicast code

Antonion Quartulli says:

====================
pull request net: batman-adv 20140527

here you have another very small fix intended for net/linux-3.15.
It prevents some multicast functions from dereferencing a NULL pointer.
(Actually it was nothing more than a typo)
I hope it is not too late for such a small patch.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>batman-adv: fix NULL pointer dereferences</title>
<updated>2014-05-31T08:07:14Z</updated>
<author>
<name>Marek Lindner</name>
<email>mareklindner@neomailbox.ch</email>
</author>
<published>2014-04-23T19:41:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=af0a171c07174661db71f92e442d4e6e90984b77'/>
<id>urn:sha1:af0a171c07174661db71f92e442d4e6e90984b77</id>
<content type='text'>
Was introduced with 4c8755d69cbde2ec464a39c932aed0a83f9ff89f
("batman-adv: Send multicast packets to nodes with a WANT_ALL flag")

Reported-by: Sven Eckelmann &lt;sven@narfation.org&gt;
Signed-off-by: Marek Lindner &lt;mareklindner@neomailbox.ch&gt;
Acked-by: Antonio Quartulli &lt;antonio@meshcoding.com&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@web.de&gt;
Signed-off-by: Antonio Quartulli &lt;antonio@meshcoding.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf</title>
<updated>2014-05-31T00:56:09Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-05-31T00:56:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dbfc4b698ab83494eb8a03f5f3c478cec29a4f62'/>
<id>urn:sha1:dbfc4b698ab83494eb8a03f5f3c478cec29a4f62</id>
<content type='text'>
Pablo Neira Ayuso says:

====================
The following patchset contains a late fix for IPVS:

* Fix crash when trying to remove the transport header with non-linear
  skbuffs, this was introduced in 3.6-rc. Patch from Peter Christensen
  via the IPVS folks.

I'll pass this to -stable once this hits mainstream.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
