<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.4.58</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.4.58</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.4.58'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-08-11T22:38:45Z</updated>
<entry>
<title>net_sched: info leak in atm_tc_dump_class()</title>
<updated>2013-08-11T22:38:45Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-07-30T10:23:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d5c50d2b4a7110dfec5204b755a0a7f031fe518f'/>
<id>urn:sha1:d5c50d2b4a7110dfec5204b755a0a7f031fe518f</id>
<content type='text'>
[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]

The "pvc" struct has a hole after pvc.sap_family which is not cleared.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>af_key: more info leaks in pfkey messages</title>
<updated>2013-08-11T22:38:45Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-07-28T20:04:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8e56df296aa939ad6ea3a55dc6ec69469ae3a5ea'/>
<id>urn:sha1:8e56df296aa939ad6ea3a55dc6ec69469ae3a5ea</id>
<content type='text'>
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]

This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages".  There are some struct members which don't get initialized
and could disclose small amounts of private information.

Acked-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Steffen Klassert &lt;steffen.klassert@secunet.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>
</entry>
<entry>
<title>net_sched: Fix stack info leak in cbq_dump_wrr().</title>
<updated>2013-08-11T22:38:44Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2013-07-30T07:16:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=565144e976ede82df899f30f9e7f8a9d210f60fe'/>
<id>urn:sha1:565144e976ede82df899f30f9e7f8a9d210f60fe</id>
<content type='text'>
[ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

Make sure the reserved fields, and padding (if any), are
fully initialized.

Based upon a patch by Dan Carpenter and feedback from
Joe Perches.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup</title>
<updated>2013-08-11T22:38:44Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-07-22T21:45:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8d50892d6f963cd24104d7f821fb08b903519a6b'/>
<id>urn:sha1:8d50892d6f963cd24104d7f821fb08b903519a6b</id>
<content type='text'>
[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net-&gt;ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[&lt;ffffffffa0366b02&gt;]  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
Stack:
 ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
 [&lt;ffffffffa034d9d1&gt;] rawv6_close+0x21/0x40 [ipv6]
 [&lt;ffffffff815bdecb&gt;] inet_release+0xfb/0x220
 [&lt;ffffffff815bddf2&gt;] ? inet_release+0x22/0x220
 [&lt;ffffffffa032686f&gt;] inet6_release+0x3f/0x50 [ipv6]
 [&lt;ffffffff8151c1d9&gt;] sock_release+0x29/0xa0
 [&lt;ffffffff81525520&gt;] sk_release_kernel+0x30/0x70
 [&lt;ffffffffa034f14b&gt;] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [&lt;ffffffff8152fff9&gt;] ops_exit_list+0x39/0x60
 [&lt;ffffffff815306fb&gt;] cleanup_net+0xfb/0x1a0
 [&lt;ffffffff81075e3a&gt;] process_one_work+0x1da/0x610
 [&lt;ffffffff81075dc9&gt;] ? process_one_work+0x169/0x610
 [&lt;ffffffff81076390&gt;] worker_thread+0x120/0x3a0
 [&lt;ffffffff81076270&gt;] ? process_one_work+0x610/0x610
 [&lt;ffffffff8107da2e&gt;] kthread+0xee/0x100
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff8162a99c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 &lt;4c&gt; 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP &lt;ffff881039367bd8&gt;
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Tested-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&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>
</entry>
<entry>
<title>sctp: fully initialize sctp_outq in sctp_outq_init</title>
<updated>2013-08-11T22:38:44Z</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-06-12T18:26:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d9a6f7174337a6d02b77e37fba6ab80bcf1ea528'/>
<id>urn:sha1:d9a6f7174337a6d02b77e37fba6ab80bcf1ea528</id>
<content type='text'>
[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]

In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure.  Steve West recently asked me why I removed the q-&gt;error = 0
initalization from sctp_outq_teardown.  I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't.  sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there
instead.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Reported-by: "West, Steve (NSN - US/Fort Worth)" &lt;steve.west@nsn.com&gt;
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: netdev@vger.kernel.org
CC: davem@davemloft.net
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.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>
</entry>
<entry>
<title>sysctl net: Keep tcp_syn_retries inside the boundary</title>
<updated>2013-08-11T22:38:44Z</updated>
<author>
<name>Michal Tesar</name>
<email>mtesar@redhat.com</email>
</author>
<published>2013-07-19T12:09:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f31dfea03c3500dbf43d29c12f4bfcefc87a6557'/>
<id>urn:sha1:f31dfea03c3500dbf43d29c12f4bfcefc87a6557</id>
<content type='text'>
[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the
/proc/sys/net/ipv4/tcp_syn_retries.

Signed-off-by: Michal Tesar &lt;mtesar@redhat.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>
</entry>
<entry>
<title>mac80211: fix duplicate retransmission detection</title>
<updated>2013-08-11T22:38:42Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-07-11T20:33:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=cfc93260cc19e2dbbe1dda395d005140a6addbf9'/>
<id>urn:sha1:cfc93260cc19e2dbbe1dda395d005140a6addbf9</id>
<content type='text'>
commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such
frames.

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nl80211: fix mgmt tx status and testmode reporting for netns</title>
<updated>2013-08-11T22:38:41Z</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2013-06-25T07:17:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1053689ef41dd8de992c15425f60ff3ea90262f5'/>
<id>urn:sha1:1053689ef41dd8de992c15425f60ff3ea90262f5</id>
<content type='text'>
commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

These two events were sent to the default network
namespace.

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vlan: fix a race in egress prio management</title>
<updated>2013-07-28T23:26:08Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-07-18T16:35:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4ae71fc80a0d7efdec8d1218cf188240eb655f38'/>
<id>urn:sha1:4ae71fc80a0d7efdec8d1218cf188240eb655f38</id>
<content type='text'>
[ Upstream commit 3e3aac497513c669e1c62c71e1d552ea85c1d974 ]

egress_priority_map[] hash table updates are protected by rtnl,
and we never remove elements until device is dismantled.

We have to make sure that before inserting an new element in hash table,
all its fields are committed to memory or else another cpu could
find corrupt values and crash.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>9p: fix off by one causing access violations and memory corruption</title>
<updated>2013-07-28T23:26:05Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2013-07-11T17:16:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dd5b0b7317dfa8cf23c45fea19ef9bb9ec1cfcd4'/>
<id>urn:sha1:dd5b0b7317dfa8cf23c45fea19ef9bb9ec1cfcd4</id>
<content type='text'>
[ Upstream commit 110ecd69a9feea82a152bbf9b12aba57e6396883 ]

p9_release_pages() would attempt to dereference one value past the end of
pages[]. This would cause the following crashes:

[ 6293.171817] BUG: unable to handle kernel paging request at ffff8807c96f3000
[ 6293.174146] IP: [&lt;ffffffff8412793b&gt;] p9_release_pages+0x3b/0x60
[ 6293.176447] PGD 79c5067 PUD 82c1e3067 PMD 82c197067 PTE 80000007c96f3060
[ 6293.180060] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 6293.180060] Modules linked in:
[ 6293.180060] CPU: 62 PID: 174043 Comm: modprobe Tainted: G        W    3.10.0-next-20130710-sasha #3954
[ 6293.180060] task: ffff8807b803b000 ti: ffff880787dde000 task.ti: ffff880787dde000
[ 6293.180060] RIP: 0010:[&lt;ffffffff8412793b&gt;]  [&lt;ffffffff8412793b&gt;] p9_release_pages+0x3b/0x60
[ 6293.214316] RSP: 0000:ffff880787ddfc28  EFLAGS: 00010202
[ 6293.214316] RAX: 0000000000000001 RBX: ffff8807c96f2ff8 RCX: 0000000000000000
[ 6293.222017] RDX: ffff8807b803b000 RSI: 0000000000000001 RDI: ffffea001c7e3d40
[ 6293.222017] RBP: ffff880787ddfc48 R08: 0000000000000000 R09: 0000000000000000
[ 6293.222017] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
[ 6293.222017] R13: 0000000000000001 R14: ffff8807cc50c070 R15: ffff8807cc50c070
[ 6293.222017] FS:  00007f572641d700(0000) GS:ffff8807f3600000(0000) knlGS:0000000000000000
[ 6293.256784] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6293.256784] CR2: ffff8807c96f3000 CR3: 00000007c8e81000 CR4: 00000000000006e0
[ 6293.256784] Stack:
[ 6293.256784]  ffff880787ddfcc8 ffff880787ddfcc8 0000000000000000 ffff880787ddfcc8
[ 6293.256784]  ffff880787ddfd48 ffffffff84128be8 ffff880700000002 0000000000000001
[ 6293.256784]  ffff8807b803b000 ffff880787ddfce0 0000100000000000 0000000000000000
[ 6293.256784] Call Trace:
[ 6293.256784]  [&lt;ffffffff84128be8&gt;] p9_virtio_zc_request+0x598/0x630
[ 6293.256784]  [&lt;ffffffff8115c610&gt;] ? wake_up_bit+0x40/0x40
[ 6293.256784]  [&lt;ffffffff841209b1&gt;] p9_client_zc_rpc+0x111/0x3a0
[ 6293.256784]  [&lt;ffffffff81174b78&gt;] ? sched_clock_cpu+0x108/0x120
[ 6293.256784]  [&lt;ffffffff84122a21&gt;] p9_client_read+0xe1/0x2c0
[ 6293.256784]  [&lt;ffffffff81708a90&gt;] v9fs_file_read+0x90/0xc0
[ 6293.256784]  [&lt;ffffffff812bd073&gt;] vfs_read+0xc3/0x130
[ 6293.256784]  [&lt;ffffffff811a78bd&gt;] ? trace_hardirqs_on+0xd/0x10
[ 6293.256784]  [&lt;ffffffff812bd5a2&gt;] SyS_read+0x62/0xa0
[ 6293.256784]  [&lt;ffffffff841a1a00&gt;] tracesys+0xdd/0xe2
[ 6293.256784] Code: 66 90 48 89 fb 41 89 f5 48 8b 3f 48 85 ff 74 29 85 f6 74 25 45 31 e4 66 0f 1f 84 00 00 00 00 00 e8 eb 14 12 fd 41 ff c4 49 63 c4 &lt;48&gt; 8b 3c c3 48 85 ff 74 05 45 39 e5 75 e7 48 83 c4 08 5b 41 5c
[ 6293.256784] RIP  [&lt;ffffffff8412793b&gt;] p9_release_pages+0x3b/0x60
[ 6293.256784]  RSP &lt;ffff880787ddfc28&gt;
[ 6293.256784] CR2: ffff8807c96f3000
[ 6293.256784] ---[ end trace 50822ee72cd360fc ]---

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.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>
</entry>
</feed>
