<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/net, branch v3.18.35</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.35</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.35'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-06-06T23:11:11Z</updated>
<entry>
<title>sunrpc: fix stripping of padded MIC tokens</title>
<updated>2016-06-06T23:11:11Z</updated>
<author>
<name>Tomáš Trnka</name>
<email>ttrnka@mail.muni.cz</email>
</author>
<published>2016-05-20T14:41:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b36205bd6c2cb9a742c187a8dde544d2141e0822'/>
<id>urn:sha1:b36205bd6c2cb9a742c187a8dde544d2141e0822</id>
<content type='text'>
[ Upstream commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 ]

The length of the GSS MIC token need not be a multiple of four bytes.
It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
would previously only trim mic.len + 4 B. The remaining up to three
bytes would then trigger a check in nfs4svc_decode_compoundargs(),
leading to a "garbage args" error and mount failure:

nfs4svc_decode_compoundargs: compound not properly padded!
nfsd: failed to decode arguments!

This would prevent older clients using the pre-RFC 4121 MIC format
(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
servers using krb5i.

The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off
trailing checksum before returning decrypted or integrity authenticated
buffer").

Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..."
Signed-off-by: Tomáš Trnka &lt;ttrnka@mail.muni.cz&gt;
Cc: stable@vger.kernel.org
Acked-by: Jeff Layton &lt;jlayton@poochiereds.net&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>nf_conntrack: avoid kernel pointer value leak in slab name</title>
<updated>2016-05-18T02:25:53Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-05-14T18:11:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d0054dc58c31c386c2b1c0f82a83e456d10292a7'/>
<id>urn:sha1:d0054dc58c31c386c2b1c0f82a83e456d10292a7</id>
<content type='text'>
[ Upstream commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 ]

The slab name ends up being visible in the directory structure under
/sys, and even if you don't have access rights to the file you can see
the filenames.

Just use a 64-bit counter instead of the pointer to the 'net' structure
to generate a unique name.

This code will go away in 4.7 when the conntrack code moves to a single
kmemcache, but this is the backportable simple solution to avoiding
leaking kernel pointers to user space.

Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>nl80211: check netlink protocol in socket release notification</title>
<updated>2016-05-09T01:21:50Z</updated>
<author>
<name>Dmitry Ivanov</name>
<email>dmitrijs.ivanovs@ubnt.com</email>
</author>
<published>2016-04-06T14:23:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ad570ce34473b014b7cdda6da09f2c811beae56'/>
<id>urn:sha1:2ad570ce34473b014b7cdda6da09f2c811beae56</id>
<content type='text'>
[ Upstream commit 8f815cdde3e550e10c2736990d791f60c2ce43eb ]

A non-privileged user can create a netlink socket with the same port_id as
used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
process) with a different protocol number.

Closing this socket will then lead to the notification going to nl80211's
socket release notification handler, and possibly cause an action such as
removing a virtual interface.

Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
Since generic netlink has no notifier chain of its own, we can't fix the
problem more generically.

Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Ivanov &lt;dima@ubnt.com&gt;
[rewrite commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>tcp_cubic: do not set epoch_start in the future</title>
<updated>2016-04-23T20:45:18Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-09-17T15:38:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e912c4abafa7d306539040b1a231d277fd750be8'/>
<id>urn:sha1:e912c4abafa7d306539040b1a231d277fd750be8</id>
<content type='text'>
[ Upstream commit c2e7204d180f8efc80f27959ca9cf16fa17f67db ]

Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
is normally set at ACK processing time, not at send time.

Doing a proper fix would need to add an additional state variable,
and does not seem worth the trouble, given CUBIC bug has been there
forever before Jana noticed it.

Let's simply not set epoch_start in the future, otherwise
bictcp_update() could overflow and CUBIC would again
grow cwnd too fast.

This was detected thanks to a packetdrill test Neal wrote that was flaky
before applying this fix.

Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Cc: Jana Iyengar &lt;jri@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>tcp_cubic: better follow cubic curve after idle period</title>
<updated>2016-04-20T13:41:08Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-09-10T04:55:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3aacca81cca936538810ae97612f9132d38ba7ac'/>
<id>urn:sha1:3aacca81cca936538810ae97612f9132d38ba7ac</id>
<content type='text'>
[ Upstream commit 30927520dbae297182990bb21d08762bcc35ce1d ]

Jana Iyengar found an interesting issue on CUBIC :

The epoch is only updated/reset initially and when experiencing losses.
The delta "t" of now - epoch_start can be arbitrary large after app idle
as well as the bic_target. Consequentially the slope (inverse of
ca-&gt;cnt) would be really large, and eventually ca-&gt;cnt would be
lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.

This particularly shows up when slow_start_after_idle is disabled
as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
time.

Jana initial fix was to reset epoch_start if app limited,
but Neal pointed out it would ask the CUBIC algorithm to recalculate the
curve so that we again start growing steeply upward from where cwnd is
now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
curve to be the same shape, just shifted later in time by the amount of
the idle period.

Reported-by: Jana Iyengar &lt;jri@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Cc: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Cc: Sangtae Ha &lt;sangtae.ha@gmail.com&gt;
Cc: Lawrence Brakmo &lt;lawrence@brakmo.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>net: Fix skb_set_peeked use-after-free bug</title>
<updated>2016-04-12T12:47:23Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2015-08-04T07:42:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fae6f76ce1a42ed2f7f6ec1ba02e29602b0ebc16'/>
<id>urn:sha1:fae6f76ce1a42ed2f7f6ec1ba02e29602b0ebc16</id>
<content type='text'>
[ Upstream commit a0a2a6602496a45ae838a96db8b8173794b5d398 ]

The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
skb before setting peeked flag") introduced a use-after-free bug
in skb_recv_datagram.  This is because skb_set_peeked may create
a new skb and free the existing one.  As it stands the caller will
continue to use the old freed skb.

This patch fixes it by making skb_set_peeked return the new skb
(or the old one if unchanged).

Fixes: 738ac1ebb96d ("net: Clone skb before setting peeked flag")
Reported-by: Brenden Blanco &lt;bblanco@plumgrid.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Tested-by: Brenden Blanco &lt;bblanco@plumgrid.com&gt;
Reviewed-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>net: Clone skb before setting peeked flag</title>
<updated>2016-04-12T12:47:15Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2015-07-13T08:04:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9f0b813dfce98f289ca6511f20c9ab38c5670027'/>
<id>urn:sha1:9f0b813dfce98f289ca6511f20c9ab38c5670027</id>
<content type='text'>
[ Upstream commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ]

Shared skbs must not be modified and this is crucial for broadcast
and/or multicast paths where we use it as an optimisation to avoid
unnecessary cloning.

The function skb_recv_datagram breaks this rule by setting peeked
without cloning the skb first.  This causes funky races which leads
to double-free.

This patch fixes this by cloning the skb and replacing the skb
in the list when setting skb-&gt;peeked.

Fixes: a59322be07c9 ("[UDP]: Only increment counter on first peek/recv")
Reported-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
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: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Fix Public Action frame RX in AP mode</title>
<updated>2016-03-22T15:11:07Z</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2016-02-29T22:29:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1c767580d56097105f1e45bc9b71582599ea5638'/>
<id>urn:sha1:1c767580d56097105f1e45bc9b71582599ea5638</id>
<content type='text'>
[ Upstream commit 1ec7bae8bec9b72e347e01330c745ab5cdd66f0e ]

Public Action frames use special rules for how the BSSID field (Address
3) is set. A wildcard BSSID is used in cases where the transmitter and
recipient are not members of the same BSS. As such, we need to accept
Public Action frames with wildcard BSSID.

Commit db8e17324553 ("mac80211: ignore frames between TDLS peers when
operating as AP") added a rule that drops Action frames to TDLS-peers
based on an Action frame having different DA (Address 1) and BSSID
(Address 3) values. This is not correct since it misses the possibility
of BSSID being a wildcard BSSID in which case the Address 1 would not
necessarily match.

Fix this by allowing mac80211 to accept wildcard BSSID in an Action
frame when in AP mode.

Fixes: db8e17324553 ("mac80211: ignore frames between TDLS peers when operating as AP")
Cc: stable@vger.kernel.org
Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>mac80211: minstrel_ht: set default tx aggregation timeout to 0</title>
<updated>2016-03-21T02:14:20Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2016-02-18T18:49:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cd9cd1897ee4a25d347f487931d79d2d8694e52f'/>
<id>urn:sha1:cd9cd1897ee4a25d347f487931d79d2d8694e52f</id>
<content type='text'>
[ Upstream commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 ]

The value 5000 was put here with the addition of the timeout field to
ieee80211_start_tx_ba_session. It was originally added in mac80211 to
save resources for drivers like iwlwifi, which only supports a limited
number of concurrent aggregation sessions.

Since iwlwifi does not use minstrel_ht and other drivers don't need
this, 0 is a better default - especially since there have been
recent reports of aggregation setup related issues reproduced with
ath9k. This should improve stability without causing any adverse
effects.

Cc: stable@vger.kernel.org
Acked-by: Avery Pennarun &lt;apenwarr@gmail.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix use of uninitialised values in RX aggregation</title>
<updated>2016-03-21T02:13:55Z</updated>
<author>
<name>Chris Bainbridge</name>
<email>chris.bainbridge@gmail.com</email>
</author>
<published>2016-01-27T15:46:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9fea93e6f0ffb4b9f9f852e66720852a3a8cf06d'/>
<id>urn:sha1:9fea93e6f0ffb4b9f9f852e66720852a3a8cf06d</id>
<content type='text'>
[ Upstream commit f39ea2690bd61efec97622c48323f40ed6e16317 ]

Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
initialize the "removed" field (all others are initialized
manually). That fixes:

UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
load of value 2 is not a valid value for type '_Bool'
CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
Workqueue: phy0 rt2x00usb_work_rxdone
 0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
 ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
 ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
Call Trace:
 [&lt;ffffffff8181d866&gt;] dump_stack+0x45/0x5f
 [&lt;ffffffff8188422d&gt;] ubsan_epilogue+0xd/0x40
 [&lt;ffffffff81884747&gt;] __ubsan_handle_load_invalid_value+0x67/0x70
 [&lt;ffffffff82227b4d&gt;] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
 [&lt;ffffffff8222ca14&gt;] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
 [&lt;ffffffff8222db03&gt;] __ieee80211_rx_handle_packet+0x1f3/0x750
 [&lt;ffffffff8222e4a7&gt;] ieee80211_rx_napi+0x447/0x990

While at it, convert to use sizeof(*tid_agg_rx) instead.

Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
[reword commit message, use sizeof(*tid_agg_rx)]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
</feed>
