<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/ppp, branch v4.3.5</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ppp, slip: Validate VJ compression slot parameters completely</title>
<updated>2016-01-31T19:25:51+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2015-11-01T16:22:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6b4fa561e26526c62636414d267342c945084f44'/>
<id>6b4fa561e26526c62636414d267342c945084f44</id>
<content type='text'>
[ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 &lt;guoyonggang@360.cn&gt;
References: http://article.gmane.org/gmane.comp.security.oss.general/17908
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 &lt;guoyonggang@360.cn&gt;
References: http://article.gmane.org/gmane.comp.security.oss.general/17908
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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>pptp: verify sockaddr_len in pptp_bind() and pptp_connect()</title>
<updated>2016-01-23T04:55:48+00:00</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-12-14T21:48:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eb414863e52e4dc8763f34f5ac9c41b3ba654850'/>
<id>eb414863e52e4dc8763f34f5ac9c41b3ba654850</id>
<content type='text'>
[ Upstream commit 09ccfd238e5a0e670d8178cf50180ea81ae09ae1 ]

Reported-by: Dmitry Vyukov &lt;dvyukov@gmail.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 09ccfd238e5a0e670d8178cf50180ea81ae09ae1 ]

Reported-by: Dmitry Vyukov &lt;dvyukov@gmail.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>pppoe: fix memory corruption in padt work structure</title>
<updated>2016-01-23T04:55:43+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-12-03T15:49:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c3dacf7144ae1ca81739a9f08e6164956cf1df7d'/>
<id>c3dacf7144ae1ca81739a9f08e6164956cf1df7d</id>
<content type='text'>
[ Upstream commit fe53985aaac83d516b38358d4f39921d9942a0e2 ]

pppoe_connect() mustn't touch the padt_work field of pppoe sockets
because that work could be already pending.

[   21.473147] BUG: unable to handle kernel NULL pointer dereference at 00000004
[   21.474523] IP: [&lt;c1043177&gt;] process_one_work+0x29/0x31c
[   21.475164] *pde = 00000000
[   21.475513] Oops: 0000 [#1] SMP
[   21.475910] Modules linked in: pppoe pppox ppp_generic slhc crc32c_intel aesni_intel virtio_net xts aes_i586 lrw gf128mul ablk_helper cryptd evdev acpi_cpufreq processor serio_raw button ext4 crc16 mbcache jbd2 virtio_blk virtio_pci virtio_ring virtio
[   21.476168] CPU: 2 PID: 164 Comm: kworker/2:2 Not tainted 4.4.0-rc1 #1
[   21.476168] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[   21.476168] task: f5f83c00 ti: f5e28000 task.ti: f5e28000
[   21.476168] EIP: 0060:[&lt;c1043177&gt;] EFLAGS: 00010046 CPU: 2
[   21.476168] EIP is at process_one_work+0x29/0x31c
[   21.484082] EAX: 00000000 EBX: f678b2a0 ECX: 00000004 EDX: 00000000
[   21.484082] ESI: f6c69940 EDI: f5e29ef0 EBP: f5e29f0c ESP: f5e29edc
[   21.484082]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[   21.484082] CR0: 80050033 CR2: 000000a4 CR3: 317ad000 CR4: 00040690
[   21.484082] Stack:
[   21.484082]  00000000 f6c69950 00000000 f6c69940 c0042338 f5e29f0c c1327945 00000000
[   21.484082]  00000008 f678b2a0 f6c69940 f678b2b8 f5e29f30 c1043984 f5f83c00 f6c69970
[   21.484082]  f678b2a0 c10437d3 f6775e80 f678b2a0 c10437d3 f5e29fac c1047059 f5e29f74
[   21.484082] Call Trace:
[   21.484082]  [&lt;c1327945&gt;] ? _raw_spin_lock_irq+0x28/0x30
[   21.484082]  [&lt;c1043984&gt;] worker_thread+0x1b1/0x244
[   21.484082]  [&lt;c10437d3&gt;] ? rescuer_thread+0x229/0x229
[   21.484082]  [&lt;c10437d3&gt;] ? rescuer_thread+0x229/0x229
[   21.484082]  [&lt;c1047059&gt;] kthread+0x8f/0x94
[   21.484082]  [&lt;c1327a32&gt;] ? _raw_spin_unlock_irq+0x22/0x26
[   21.484082]  [&lt;c1327ee9&gt;] ret_from_kernel_thread+0x21/0x38
[   21.484082]  [&lt;c1046fca&gt;] ? kthread_parkme+0x19/0x19
[   21.496082] Code: 5d c3 55 89 e5 57 56 53 89 c3 83 ec 24 89 d0 89 55 e0 8d 7d e4 e8 6c d8 ff ff b9 04 00 00 00 89 45 d8 8b 43 24 89 45 dc 8b 45 d8 &lt;8b&gt; 40 04 8b 80 e0 00 00 00 c1 e8 05 24 01 88 45 d7 8b 45 e0 8d
[   21.496082] EIP: [&lt;c1043177&gt;] process_one_work+0x29/0x31c SS:ESP 0068:f5e29edc
[   21.496082] CR2: 0000000000000004
[   21.496082] ---[ end trace e362cc9cf10dae89 ]---

Reported-by: Andrew &lt;nitr0@seti.kr.ua&gt;
Fixes: 287f3a943fef ("pppoe: Use workqueue to die properly when a PADT is received")
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&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 fe53985aaac83d516b38358d4f39921d9942a0e2 ]

pppoe_connect() mustn't touch the padt_work field of pppoe sockets
because that work could be already pending.

[   21.473147] BUG: unable to handle kernel NULL pointer dereference at 00000004
[   21.474523] IP: [&lt;c1043177&gt;] process_one_work+0x29/0x31c
[   21.475164] *pde = 00000000
[   21.475513] Oops: 0000 [#1] SMP
[   21.475910] Modules linked in: pppoe pppox ppp_generic slhc crc32c_intel aesni_intel virtio_net xts aes_i586 lrw gf128mul ablk_helper cryptd evdev acpi_cpufreq processor serio_raw button ext4 crc16 mbcache jbd2 virtio_blk virtio_pci virtio_ring virtio
[   21.476168] CPU: 2 PID: 164 Comm: kworker/2:2 Not tainted 4.4.0-rc1 #1
[   21.476168] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[   21.476168] task: f5f83c00 ti: f5e28000 task.ti: f5e28000
[   21.476168] EIP: 0060:[&lt;c1043177&gt;] EFLAGS: 00010046 CPU: 2
[   21.476168] EIP is at process_one_work+0x29/0x31c
[   21.484082] EAX: 00000000 EBX: f678b2a0 ECX: 00000004 EDX: 00000000
[   21.484082] ESI: f6c69940 EDI: f5e29ef0 EBP: f5e29f0c ESP: f5e29edc
[   21.484082]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[   21.484082] CR0: 80050033 CR2: 000000a4 CR3: 317ad000 CR4: 00040690
[   21.484082] Stack:
[   21.484082]  00000000 f6c69950 00000000 f6c69940 c0042338 f5e29f0c c1327945 00000000
[   21.484082]  00000008 f678b2a0 f6c69940 f678b2b8 f5e29f30 c1043984 f5f83c00 f6c69970
[   21.484082]  f678b2a0 c10437d3 f6775e80 f678b2a0 c10437d3 f5e29fac c1047059 f5e29f74
[   21.484082] Call Trace:
[   21.484082]  [&lt;c1327945&gt;] ? _raw_spin_lock_irq+0x28/0x30
[   21.484082]  [&lt;c1043984&gt;] worker_thread+0x1b1/0x244
[   21.484082]  [&lt;c10437d3&gt;] ? rescuer_thread+0x229/0x229
[   21.484082]  [&lt;c10437d3&gt;] ? rescuer_thread+0x229/0x229
[   21.484082]  [&lt;c1047059&gt;] kthread+0x8f/0x94
[   21.484082]  [&lt;c1327a32&gt;] ? _raw_spin_unlock_irq+0x22/0x26
[   21.484082]  [&lt;c1327ee9&gt;] ret_from_kernel_thread+0x21/0x38
[   21.484082]  [&lt;c1046fca&gt;] ? kthread_parkme+0x19/0x19
[   21.496082] Code: 5d c3 55 89 e5 57 56 53 89 c3 83 ec 24 89 d0 89 55 e0 8d 7d e4 e8 6c d8 ff ff b9 04 00 00 00 89 45 d8 8b 43 24 89 45 dc 8b 45 d8 &lt;8b&gt; 40 04 8b 80 e0 00 00 00 c1 e8 05 24 01 88 45 d7 8b 45 e0 8d
[   21.496082] EIP: [&lt;c1043177&gt;] process_one_work+0x29/0x31c SS:ESP 0068:f5e29edc
[   21.496082] CR2: 0000000000000004
[   21.496082] ---[ end trace e362cc9cf10dae89 ]---

Reported-by: Andrew &lt;nitr0@seti.kr.ua&gt;
Fixes: 287f3a943fef ("pppoe: Use workqueue to die properly when a PADT is received")
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&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>ppp: fix pppoe_dev deletion condition in pppoe_release()</title>
<updated>2015-10-23T10:30:01+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-10-22T14:57:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1acea4f6ce1b1c0941438aca75dd2e5c6b09db60'/>
<id>1acea4f6ce1b1c0941438aca75dd2e5c6b09db60</id>
<content type='text'>
We can't rely on PPPOX_ZOMBIE to decide whether to clear po-&gt;pppoe_dev.
PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po-&gt;pppoe_dev is
NULL. So we have no guarantee that (sk-&gt;sk_state &amp; PPPOX_ZOMBIE) implies
(po-&gt;pppoe_dev != NULL).
Since we're releasing a PPPoE socket, we want to release the pppoe_dev
if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
value of sk_state. So we can just check for po-&gt;pppoe_dev and avoid any
assumption on sk-&gt;sk_state.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We can't rely on PPPOX_ZOMBIE to decide whether to clear po-&gt;pppoe_dev.
PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po-&gt;pppoe_dev is
NULL. So we have no guarantee that (sk-&gt;sk_state &amp; PPPOX_ZOMBIE) implies
(po-&gt;pppoe_dev != NULL).
Since we're releasing a PPPoE socket, we want to release the pppoe_dev
if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
value of sk_state. So we can just check for po-&gt;pppoe_dev and avoid any
assumption on sk-&gt;sk_state.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ppp: don't override sk-&gt;sk_state in pppoe_flush_dev()</title>
<updated>2015-10-05T10:04:15+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-09-30T09:45:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6740165b8f7f06d8caee0fceab3fb9d790a6fed'/>
<id>e6740165b8f7f06d8caee0fceab3fb9d790a6fed</id>
<content type='text'>
Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po-&gt;pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk-&gt;sk_state to
PPPOX_ZOMBIE _and_ reset po-&gt;pppoe_dev to NULL. This leads to the
following oops:

[  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
[  570.142931] IP: [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
[  570.144601] Oops: 0000 [#1] SMP
[  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
[  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
[  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
[  570.144601] RIP: 0010:[&lt;ffffffffa018c701&gt;]  [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
[  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
[  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
[  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
[  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
[  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
[  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
[  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
[  570.144601] Stack:
[  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
[  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
[  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
[  570.144601] Call Trace:
[  570.144601]  [&lt;ffffffff812caabe&gt;] sock_release+0x1a/0x75
[  570.144601]  [&lt;ffffffff812cabad&gt;] sock_close+0xd/0x11
[  570.144601]  [&lt;ffffffff811347f5&gt;] __fput+0xff/0x1a5
[  570.144601]  [&lt;ffffffff811348cb&gt;] ____fput+0x9/0xb
[  570.144601]  [&lt;ffffffff81056682&gt;] task_work_run+0x66/0x90
[  570.144601]  [&lt;ffffffff8100189e&gt;] prepare_exit_to_usermode+0x8c/0xa7
[  570.144601]  [&lt;ffffffff81001a26&gt;] syscall_return_slowpath+0x16d/0x19b
[  570.144601]  [&lt;ffffffff813babb1&gt;] int_ret_from_sys_call+0x25/0x9f
[  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 &lt;48&gt; 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
[  570.144601] RIP  [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601]  RSP &lt;ffff880036b63e08&gt;
[  570.144601] CR2: 00000000000004e0
[  570.200518] ---[ end trace 46956baf17349563 ]---

pppoe_flush_dev() has no reason to override sk-&gt;sk_state with
PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk-&gt;sk_state to
PPPOX_DEAD, which is the correct state given that sk is unbound and
po-&gt;pppoe_dev is NULL.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Tested-by: Oleksii Berezhniak &lt;core@irc.lg.ua&gt;
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po-&gt;pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk-&gt;sk_state to
PPPOX_ZOMBIE _and_ reset po-&gt;pppoe_dev to NULL. This leads to the
following oops:

[  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
[  570.142931] IP: [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
[  570.144601] Oops: 0000 [#1] SMP
[  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
[  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
[  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
[  570.144601] RIP: 0010:[&lt;ffffffffa018c701&gt;]  [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
[  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
[  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
[  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
[  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
[  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
[  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
[  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
[  570.144601] Stack:
[  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
[  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
[  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
[  570.144601] Call Trace:
[  570.144601]  [&lt;ffffffff812caabe&gt;] sock_release+0x1a/0x75
[  570.144601]  [&lt;ffffffff812cabad&gt;] sock_close+0xd/0x11
[  570.144601]  [&lt;ffffffff811347f5&gt;] __fput+0xff/0x1a5
[  570.144601]  [&lt;ffffffff811348cb&gt;] ____fput+0x9/0xb
[  570.144601]  [&lt;ffffffff81056682&gt;] task_work_run+0x66/0x90
[  570.144601]  [&lt;ffffffff8100189e&gt;] prepare_exit_to_usermode+0x8c/0xa7
[  570.144601]  [&lt;ffffffff81001a26&gt;] syscall_return_slowpath+0x16d/0x19b
[  570.144601]  [&lt;ffffffff813babb1&gt;] int_ret_from_sys_call+0x25/0x9f
[  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 &lt;48&gt; 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
[  570.144601] RIP  [&lt;ffffffffa018c701&gt;] pppoe_release+0x50/0x101 [pppoe]
[  570.144601]  RSP &lt;ffff880036b63e08&gt;
[  570.144601] CR2: 00000000000004e0
[  570.200518] ---[ end trace 46956baf17349563 ]---

pppoe_flush_dev() has no reason to override sk-&gt;sk_state with
PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk-&gt;sk_state to
PPPOX_DEAD, which is the correct state given that sk is unbound and
po-&gt;pppoe_dev is NULL.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Tested-by: Oleksii Berezhniak &lt;core@irc.lg.ua&gt;
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ppp: fix lockdep splat in ppp_dev_uninit()</title>
<updated>2015-09-25T19:38:11+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-09-24T10:54:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=58a89ecaca53736aa465170530acea4f8be34ab4'/>
<id>58a89ecaca53736aa465170530acea4f8be34ab4</id>
<content type='text'>
ppp_dev_uninit() locks all_ppp_mutex while under rtnl mutex protection.
ppp_create_interface() must then lock these mutexes in that same order
to avoid possible deadlock.

[  120.880011] ======================================================
[  120.880011] [ INFO: possible circular locking dependency detected ]
[  120.880011] 4.2.0 #1 Not tainted
[  120.880011] -------------------------------------------------------
[  120.880011] ppp-apitest/15827 is trying to acquire lock:
[  120.880011]  (&amp;pn-&gt;all_ppp_mutex){+.+.+.}, at: [&lt;ffffffffa0145f56&gt;] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[  120.880011]
[  120.880011] but task is already holding lock:
[  120.880011]  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff812e4255&gt;] rtnl_lock+0x12/0x14
[  120.880011]
[  120.880011] which lock already depends on the new lock.
[  120.880011]
[  120.880011]
[  120.880011] the existing dependency chain (in reverse order) is:
[  120.880011]
[  120.880011] -&gt; #1 (rtnl_mutex){+.+.+.}:
[  120.880011]        [&lt;ffffffff81073a6f&gt;] lock_acquire+0xcf/0x10e
[  120.880011]        [&lt;ffffffff813ab18a&gt;] mutex_lock_nested+0x56/0x341
[  120.880011]        [&lt;ffffffff812e4255&gt;] rtnl_lock+0x12/0x14
[  120.880011]        [&lt;ffffffff812d9d94&gt;] register_netdev+0x11/0x27
[  120.880011]        [&lt;ffffffffa0147b17&gt;] ppp_ioctl+0x289/0xc98 [ppp_generic]
[  120.880011]        [&lt;ffffffff8113b367&gt;] do_vfs_ioctl+0x4ea/0x532
[  120.880011]        [&lt;ffffffff8113b3fd&gt;] SyS_ioctl+0x4e/0x7d
[  120.880011]        [&lt;ffffffff813ad7d7&gt;] entry_SYSCALL_64_fastpath+0x12/0x6f
[  120.880011]
[  120.880011] -&gt; #0 (&amp;pn-&gt;all_ppp_mutex){+.+.+.}:
[  120.880011]        [&lt;ffffffff8107334e&gt;] __lock_acquire+0xb07/0xe76
[  120.880011]        [&lt;ffffffff81073a6f&gt;] lock_acquire+0xcf/0x10e
[  120.880011]        [&lt;ffffffff813ab18a&gt;] mutex_lock_nested+0x56/0x341
[  120.880011]        [&lt;ffffffffa0145f56&gt;] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[  120.880011]        [&lt;ffffffff812d5263&gt;] rollback_registered_many+0x19e/0x252
[  120.880011]        [&lt;ffffffff812d5381&gt;] rollback_registered+0x29/0x38
[  120.880011]        [&lt;ffffffff812d53fa&gt;] unregister_netdevice_queue+0x6a/0x77
[  120.880011]        [&lt;ffffffffa0146a94&gt;] ppp_release+0x42/0x79 [ppp_generic]
[  120.880011]        [&lt;ffffffff8112d9f6&gt;] __fput+0xec/0x192
[  120.880011]        [&lt;ffffffff8112dacc&gt;] ____fput+0x9/0xb
[  120.880011]        [&lt;ffffffff8105447a&gt;] task_work_run+0x66/0x80
[  120.880011]        [&lt;ffffffff81001801&gt;] prepare_exit_to_usermode+0x8c/0xa7
[  120.880011]        [&lt;ffffffff81001900&gt;] syscall_return_slowpath+0xe4/0x104
[  120.880011]        [&lt;ffffffff813ad931&gt;] int_ret_from_sys_call+0x25/0x9f
[  120.880011]
[  120.880011] other info that might help us debug this:
[  120.880011]
[  120.880011]  Possible unsafe locking scenario:
[  120.880011]
[  120.880011]        CPU0                    CPU1
[  120.880011]        ----                    ----
[  120.880011]   lock(rtnl_mutex);
[  120.880011]                                lock(&amp;pn-&gt;all_ppp_mutex);
[  120.880011]                                lock(rtnl_mutex);
[  120.880011]   lock(&amp;pn-&gt;all_ppp_mutex);
[  120.880011]
[  120.880011]  *** DEADLOCK ***

Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion")
Reported-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ppp_dev_uninit() locks all_ppp_mutex while under rtnl mutex protection.
ppp_create_interface() must then lock these mutexes in that same order
to avoid possible deadlock.

[  120.880011] ======================================================
[  120.880011] [ INFO: possible circular locking dependency detected ]
[  120.880011] 4.2.0 #1 Not tainted
[  120.880011] -------------------------------------------------------
[  120.880011] ppp-apitest/15827 is trying to acquire lock:
[  120.880011]  (&amp;pn-&gt;all_ppp_mutex){+.+.+.}, at: [&lt;ffffffffa0145f56&gt;] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[  120.880011]
[  120.880011] but task is already holding lock:
[  120.880011]  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff812e4255&gt;] rtnl_lock+0x12/0x14
[  120.880011]
[  120.880011] which lock already depends on the new lock.
[  120.880011]
[  120.880011]
[  120.880011] the existing dependency chain (in reverse order) is:
[  120.880011]
[  120.880011] -&gt; #1 (rtnl_mutex){+.+.+.}:
[  120.880011]        [&lt;ffffffff81073a6f&gt;] lock_acquire+0xcf/0x10e
[  120.880011]        [&lt;ffffffff813ab18a&gt;] mutex_lock_nested+0x56/0x341
[  120.880011]        [&lt;ffffffff812e4255&gt;] rtnl_lock+0x12/0x14
[  120.880011]        [&lt;ffffffff812d9d94&gt;] register_netdev+0x11/0x27
[  120.880011]        [&lt;ffffffffa0147b17&gt;] ppp_ioctl+0x289/0xc98 [ppp_generic]
[  120.880011]        [&lt;ffffffff8113b367&gt;] do_vfs_ioctl+0x4ea/0x532
[  120.880011]        [&lt;ffffffff8113b3fd&gt;] SyS_ioctl+0x4e/0x7d
[  120.880011]        [&lt;ffffffff813ad7d7&gt;] entry_SYSCALL_64_fastpath+0x12/0x6f
[  120.880011]
[  120.880011] -&gt; #0 (&amp;pn-&gt;all_ppp_mutex){+.+.+.}:
[  120.880011]        [&lt;ffffffff8107334e&gt;] __lock_acquire+0xb07/0xe76
[  120.880011]        [&lt;ffffffff81073a6f&gt;] lock_acquire+0xcf/0x10e
[  120.880011]        [&lt;ffffffff813ab18a&gt;] mutex_lock_nested+0x56/0x341
[  120.880011]        [&lt;ffffffffa0145f56&gt;] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
[  120.880011]        [&lt;ffffffff812d5263&gt;] rollback_registered_many+0x19e/0x252
[  120.880011]        [&lt;ffffffff812d5381&gt;] rollback_registered+0x29/0x38
[  120.880011]        [&lt;ffffffff812d53fa&gt;] unregister_netdevice_queue+0x6a/0x77
[  120.880011]        [&lt;ffffffffa0146a94&gt;] ppp_release+0x42/0x79 [ppp_generic]
[  120.880011]        [&lt;ffffffff8112d9f6&gt;] __fput+0xec/0x192
[  120.880011]        [&lt;ffffffff8112dacc&gt;] ____fput+0x9/0xb
[  120.880011]        [&lt;ffffffff8105447a&gt;] task_work_run+0x66/0x80
[  120.880011]        [&lt;ffffffff81001801&gt;] prepare_exit_to_usermode+0x8c/0xa7
[  120.880011]        [&lt;ffffffff81001900&gt;] syscall_return_slowpath+0xe4/0x104
[  120.880011]        [&lt;ffffffff813ad931&gt;] int_ret_from_sys_call+0x25/0x9f
[  120.880011]
[  120.880011] other info that might help us debug this:
[  120.880011]
[  120.880011]  Possible unsafe locking scenario:
[  120.880011]
[  120.880011]        CPU0                    CPU1
[  120.880011]        ----                    ----
[  120.880011]   lock(rtnl_mutex);
[  120.880011]                                lock(&amp;pn-&gt;all_ppp_mutex);
[  120.880011]                                lock(rtnl_mutex);
[  120.880011]   lock(&amp;pn-&gt;all_ppp_mutex);
[  120.880011]
[  120.880011]  *** DEADLOCK ***

Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion")
Reported-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ppp: implement x-netns support</title>
<updated>2015-08-25T21:11:20+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-08-24T09:35:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79c441ae505ccfaed9d80df95e83fb2573f23f8e'/>
<id>79c441ae505ccfaed9d80df95e83fb2573f23f8e</id>
<content type='text'>
Let packets move from one netns to the other at PPP encapsulation and
decapsulation time.

PPP units and channels remain in the netns in which they were
originally created. Only the net_device may move to a different
namespace. Cross netns handling is thus transparent to lower PPP
layers (PPPoE, L2TP, etc.).

PPP devices are automatically unregistered when their netns gets
removed. So read() and poll() on the unit file descriptor will
respectively receive EOF and POLLHUP. Channels aren't affected.

Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Let packets move from one netns to the other at PPP encapsulation and
decapsulation time.

PPP units and channels remain in the netns in which they were
originally created. Only the net_device may move to a different
namespace. Cross netns handling is thus transparent to lower PPP
layers (PPPoE, L2TP, etc.).

PPP devices are automatically unregistered when their netns gets
removed. So read() and poll() on the unit file descriptor will
respectively receive EOF and POLLHUP. Channels aren't affected.

Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ppp: fix device unregistration upon netns deletion</title>
<updated>2015-08-17T19:22:20+00:00</updated>
<author>
<name>Guillaume Nault</name>
<email>g.nault@alphalink.fr</email>
</author>
<published>2015-08-14T08:42:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8cb775bc0a34dc596837e7da03fd22c747be618b'/>
<id>8cb775bc0a34dc596837e7da03fd22c747be618b</id>
<content type='text'>
PPP devices may get automatically unregistered when their network
namespace is getting removed. This happens if the ppp control plane
daemon (e.g. pppd) exits while it is the last user of this namespace.

This leads to several races:

  * ppp_exit_net() may destroy the per namespace idr (pn-&gt;units_idr)
    before all file descriptors were released. Successive ppp_release()
    calls may then cleanup PPP devices with ppp_shutdown_interface() and
    try to use the already destroyed idr.

  * Automatic device unregistration may also happen before the
    ppp_release() call for that device gets executed. Once called on
    the file owning the device, ppp_release() will then clean it up and
    try to unregister it a second time.

To fix these issues, operations defined in ppp_shutdown_interface() are
moved to the PPP device's ndo_uninit() callback. This allows PPP
devices to be properly cleaned up by unregister_netdev() and friends.
So checking for ppp-&gt;owner is now an accurate test to decide if a PPP
device should be unregistered.

Setting ppp-&gt;owner is done in ppp_create_interface(), before device
registration, in order to avoid unprotected modification of this field.

Finally, ppp_exit_net() now starts by unregistering all remaining PPP
devices to ensure that none will get unregistered after the call to
idr_destroy().

Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PPP devices may get automatically unregistered when their network
namespace is getting removed. This happens if the ppp control plane
daemon (e.g. pppd) exits while it is the last user of this namespace.

This leads to several races:

  * ppp_exit_net() may destroy the per namespace idr (pn-&gt;units_idr)
    before all file descriptors were released. Successive ppp_release()
    calls may then cleanup PPP devices with ppp_shutdown_interface() and
    try to use the already destroyed idr.

  * Automatic device unregistration may also happen before the
    ppp_release() call for that device gets executed. Once called on
    the file owning the device, ppp_release() will then clean it up and
    try to unregister it a second time.

To fix these issues, operations defined in ppp_shutdown_interface() are
moved to the PPP device's ndo_uninit() callback. This allows PPP
devices to be properly cleaned up by unregister_netdev() and friends.
So checking for ppp-&gt;owner is now an accurate test to decide if a PPP
device should be unregistered.

Setting ppp-&gt;owner is done in ppp_create_interface(), before device
registration, in order to avoid unprotected modification of this field.

Finally, ppp_exit_net() now starts by unregistering all remaining PPP
devices to ensure that none will get unregistered after the call to
idr_destroy().

Signed-off-by: Guillaume Nault &lt;g.nault@alphalink.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: Remove spurios included of netfilter.h</title>
<updated>2015-06-18T19:14:32+00:00</updated>
<author>
<name>Eric W Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-06-17T15:28:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8f481b50ea653ff0aea6accbb4bb02a15cf00531'/>
<id>8f481b50ea653ff0aea6accbb4bb02a15cf00531</id>
<content type='text'>
While testing my netfilter changes I noticed several files where
recompiling unncessarily because they unncessarily included
netfilter.h.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While testing my netfilter changes I noticed several files where
recompiling unncessarily because they unncessarily included
netfilter.h.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-05-13T18:31:43+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-05-13T18:31:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b04096ff33a977c01c8780ca3ee129dbd641bad4'/>
<id>b04096ff33a977c01c8780ca3ee129dbd641bad4</id>
<content type='text'>
Four minor merge conflicts:

1) qca_spi.c renamed the local variable used for the SPI device
   from spi_device to spi, meanwhile the spi_set_drvdata() call
   got moved further up in the probe function.

2) Two changes were both adding new members to codel params
   structure, and thus we had overlapping changes to the
   initializer function.

3) 'net' was making a fix to sk_release_kernel() which is
   completely removed in 'net-next'.

4) In net_namespace.c, the rtnl_net_fill() call for GET operations
   had the command value fixed, meanwhile 'net-next' adjusted the
   argument signature a bit.

This also matches example merge resolutions posted by Stephen
Rothwell over the past two days.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Four minor merge conflicts:

1) qca_spi.c renamed the local variable used for the SPI device
   from spi_device to spi, meanwhile the spi_set_drvdata() call
   got moved further up in the probe function.

2) Two changes were both adding new members to codel params
   structure, and thus we had overlapping changes to the
   initializer function.

3) 'net' was making a fix to sk_release_kernel() which is
   completely removed in 'net-next'.

4) In net_namespace.c, the rtnl_net_fill() call for GET operations
   had the command value fixed, meanwhile 'net-next' adjusted the
   argument signature a bit.

This also matches example merge resolutions posted by Stephen
Rothwell over the past two days.

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