Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1614508 > unrolled thread

[PATCH 3.2 0/4] 3.2.88-rc1 review

Back to article view | Back to linux.kernel

Contents

  [PATCH 3.2 0/4] 3.2.88-rc1 review Ben Hutchings <ben@decadent.org.uk> - 2017-04-01 15:30 +0200
    [PATCH 3.2 3/4] l2tp: fix racy SOCK_ZAPPED flag check in  l2tp_ip{,6}_bind() Ben Hutchings <ben@decadent.org.uk> - 2017-04-01 15:30 +0200
    [PATCH 3.2 4/4] keys: Guard against null match function in  keyring_search_aux() Ben Hutchings <ben@decadent.org.uk> - 2017-04-01 15:30 +0200
    [PATCH 3.2 2/4] mm/huge_memory.c: fix up "mm/huge_memory.c:  respect FOLL_FORCE/FOLL_COW for thp" backport Ben Hutchings <ben@decadent.org.uk> - 2017-04-01 15:30 +0200
    [PATCH 3.2 1/4] ipv4: keep skb->dst around in presence of IP  options Ben Hutchings <ben@decadent.org.uk> - 2017-04-01 15:30 +0200
    Re: [PATCH 3.2 0/4] 3.2.88-rc1 review Guenter Roeck <linux@roeck-us.net> - 2017-04-01 19:30 +0200
      Re: [PATCH 3.2 0/4] 3.2.88-rc1 review Ben Hutchings <ben@decadent.org.uk> - 2017-04-02 00:50 +0200
    Re: [PATCH 3.2 0/4] 3.2.88-rc1 review Ben Hutchings <ben@decadent.org.uk> - 2017-04-02 05:10 +0200

#1614508 — [PATCH 3.2 0/4] 3.2.88-rc1 review

This is the start of the stable review cycle for the 3.2.88 release.
There are 4 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue Apr 04 00:00:00 UTC 2017.
Anything received after that time might be too late.

A combined patch relative to 3.2.87 will be posted as an additional
response to this.  A shortlog and diffstat can be found below.

Ben.

-------------

Ben Hutchings (1):
      keys: Guard against null match function in keyring_search_aux()
         [c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81]

Eric Dumazet (1):
      ipv4: keep skb->dst around in presence of IP  options
         [34b2cef20f19c87999fff3da4071e66937db9644]

Guillaume Nault (1):
      l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()
         [32c231164b762dddefa13af5a0101032c70b50ef]

Michal Hocko (1):
      mm/huge_memory.c: fix up "mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp" backport
         [not upstream; fixes incorrect backport]

 Makefile                | 4 ++--
 mm/huge_memory.c        | 2 +-
 net/ipv4/ip_sockglue.c  | 3 ++-
 net/l2tp/l2tp_ip.c      | 5 +++--
 security/keys/keyring.c | 6 +++---
 5 files changed, 11 insertions(+), 9 deletions(-)

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.

[toc] | [next] | [standalone]

#1614510 — [PATCH 3.2 3/4] l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()

3.2.88-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Guillaume Nault <g.nault@alphalink.fr>

commit 32c231164b762dddefa13af5a0101032c70b50ef upstream.

Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind().
Without lock, a concurrent call could modify the socket flags between
the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way,
a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it
would then leave a stale pointer there, generating use-after-free
errors when walking through the list or modifying adjacent entries.

BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
Write of size 8 by task syz-executor/10987
CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
 ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
Call Trace:
 [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
 [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
 [<     inline     >] print_address_description mm/kasan/report.c:194
 [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
 [<     inline     >] kasan_report mm/kasan/report.c:303
 [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
 [<     inline     >] __write_once_size ./include/linux/compiler.h:249
 [<     inline     >] __hlist_del ./include/linux/list.h:622
 [<     inline     >] hlist_del_init ./include/linux/list.h:637
 [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
 [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
 [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
 [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
 [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
 [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
 [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
 [<ffffffff813774f9>] task_work_run+0xf9/0x170
 [<ffffffff81324aae>] do_exit+0x85e/0x2a00
 [<ffffffff81326dc8>] do_group_exit+0x108/0x330
 [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
 [<ffffffff811b49af>] do_signal+0x7f/0x18f0
 [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
 [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
 [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
Allocated:
PID = 10987
 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
 [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
 [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
 [ 1116.897025] [<     inline     >] slab_post_alloc_hook mm/slab.h:417
 [ 1116.897025] [<     inline     >] slab_alloc_node mm/slub.c:2708
 [ 1116.897025] [<     inline     >] slab_alloc mm/slub.c:2716
 [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
 [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
 [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
 [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
 [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
 [ 1116.897025] [<     inline     >] sock_create net/socket.c:1193
 [ 1116.897025] [<     inline     >] SYSC_socket net/socket.c:1223
 [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
 [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 10987
 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
 [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
 [ 1116.897025] [<     inline     >] slab_free_hook mm/slub.c:1352
 [ 1116.897025] [<     inline     >] slab_free_freelist_hook mm/slub.c:1374
 [ 1116.897025] [<     inline     >] slab_free mm/slub.c:2951
 [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
 [ 1116.897025] [<     inline     >] sk_prot_free net/core/sock.c:1369
 [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
 [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
 [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
 [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
 [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
 [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
 [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
 [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
 [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
 [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
 [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
 [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
 [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
 [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
 [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
 [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
 [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
 [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
 [ 1116.897025] [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
 [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
 ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                    ^
 ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

==================================================================

The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table.

Fixes: c51ce49735c1 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case")
Reported-by: Baozeng Ding <sploving1@gmail.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Baozeng Ding <sploving1@gmail.com>
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: drop IPv6 changes]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -257,8 +257,6 @@ static int l2tp_ip_bind(struct sock *sk,
 	int ret;
 	int chk_addr_ret;
 
-	if (!sock_flag(sk, SOCK_ZAPPED))
-		return -EINVAL;
 	if (addr_len < sizeof(struct sockaddr_l2tpip))
 		return -EINVAL;
 	if (addr->l2tp_family != AF_INET)
@@ -272,6 +270,9 @@ static int l2tp_ip_bind(struct sock *sk,
 	read_unlock_bh(&l2tp_ip_lock);
 
 	lock_sock(sk);
+	if (!sock_flag(sk, SOCK_ZAPPED))
+		goto out;
+
 	if (sk->sk_state != TCP_CLOSE || addr_len < sizeof(struct sockaddr_l2tpip))
 		goto out;
 

[toc] | [prev] | [next] | [standalone]

#1614513 — [PATCH 3.2 4/4] keys: Guard against null match function in keyring_search_aux()

3.2.88-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <ben@decadent.org.uk>

The "dead" key type has no match operation, and a search for keys of
this type can cause a null dereference in keyring_search_aux().
keyring_search() has a check for this, but request_keyring_and_link()
does not.  Move the check into keyring_search_aux(), covering both of
them.

This was fixed upstream by commit c06cfb08b88d ("KEYS: Remove
key_type::match in favour of overriding default by match_preparse"),
part of a series of large changes that are not suitable for
backporting.

CVE-2017-2647 / CVE-2017-6951

Reported-by: Igor Redko <redkoi@virtuozzo.com>
Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2647
Reported-by: idl3r <idler1984@gmail.com>
References: https://www.spinics.net/lists/keyrings/msg01845.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: David Howells <dhowells@redhat.com>
---
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -336,6 +336,9 @@ key_ref_t keyring_search_aux(key_ref_t k
 	if (keyring->type != &key_type_keyring)
 		goto error;
 
+	if (!match)
+		return ERR_PTR(-ENOKEY);
+
 	rcu_read_lock();
 
 	now = current_kernel_time();
@@ -484,9 +487,6 @@ key_ref_t keyring_search(key_ref_t keyri
 			 struct key_type *type,
 			 const char *description)
 {
-	if (!type->match)
-		return ERR_PTR(-ENOKEY);
-
 	return keyring_search_aux(keyring, current->cred,
 				  type, description, type->match, false);
 }

[toc] | [prev] | [next] | [standalone]

#1614520 — [PATCH 3.2 2/4] mm/huge_memory.c: fix up "mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp" backport

3.2.88-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Michal Hocko <mhocko@suse.com>

This is a stable follow up fix for an incorrect backport. The issue is
not present in the upstream kernel.

Miroslav has noticed the following splat when testing my 3.2 forward
port of 8310d48b125d ("mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for
thp") to 3.12:

BUG: Bad page state in process a.out  pfn:26400
page:ffffea000085e000 count:0 mapcount:1 mapping:          (null) index:0x7f049d600
page flags: 0x1fffff80108018(uptodate|dirty|head|swapbacked)
page dumped because: nonzero mapcount
[iii]
CPU: 2 PID: 5926 Comm: a.out Tainted: G            E    3.12.61-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
 0000000000000000 ffffffff81515830 ffffea000085e000 ffffffff81800ad7
 ffffffff815118a5 ffffea000085e000 0000000000000000 000fffff80000000
 ffffffff81140f18 fff000007c000000 ffffea000085e000 0000000000000009
Call Trace:
 [<ffffffff8100475d>] dump_trace+0x7d/0x2d0
 [<ffffffff81004a44>] show_stack_log_lvl+0x94/0x170
 [<ffffffff81005ce1>] show_stack+0x21/0x50
 [<ffffffff81515830>] dump_stack+0x5d/0x78
 [<ffffffff815118a5>] bad_page.part.67+0xe8/0x102
 [<ffffffff81140f18>] free_pages_prepare+0x198/0x1b0
 [<ffffffff81141275>] __free_pages_ok+0x15/0xd0
 [<ffffffff8116444c>] __access_remote_vm+0x7c/0x1e0
 [<ffffffff81205afb>] mem_rw.isra.13+0x14b/0x1a0
 [<ffffffff811a3b18>] vfs_write+0xb8/0x1e0
 [<ffffffff811a469b>] SyS_pwrite64+0x6b/0xa0
 [<ffffffff81523b49>] system_call_fastpath+0x16/0x1b
 [<00007f049da18573>] 0x7f049da18572

The problem is that the original 3.2 backport didn't return NULL page on
the FOLL_COW page and so the page got reused.

Reported-and-tested-by: Miroslav Beneš <mbenes@suse.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 mm/huge_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 998efcee7201..d6e6cafdb2c9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -989,7 +989,7 @@ struct page *follow_trans_huge_pmd(struct mm_struct *mm,
 	VM_BUG_ON(!PageHead(page));
 
 	if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, page, flags))
-		goto out;
+		return NULL;
 
 	if (flags & FOLL_TOUCH) {
 		pmd_t _pmd;

[toc] | [prev] | [next] | [standalone]

#1614527 — [PATCH 3.2 1/4] ipv4: keep skb->dst around in presence of IP options

3.2.88-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

Upstream commit 34b2cef20f19c87999fff3da4071e66937db9644
("ipv4: keep skb->dst around in presence of IP options") incorrectly
root caused commit d826eb14ecef ("ipv4: PKTINFO doesnt need dst
reference") as bug origin.

This patch should fix the issue for 3.2.xx stable kernels, since IPv4
options seem to get more traction these days, after years of oblivion ;)

Fixes: f84af32cbca70 ("net: ip_queue_rcv_skb() helper"))
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Anarcheuz Fritz <anarcheuz@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1009,7 +1009,8 @@ e_inval:
  */
 int ip_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 {
-	if (!(inet_sk(sk)->cmsg_flags & IP_CMSG_PKTINFO))
+	if (!(inet_sk(sk)->cmsg_flags & IP_CMSG_PKTINFO) &&
+	    !IPCB(skb)->opt.optlen)
 		skb_dst_drop(skb);
 	return sock_queue_rcv_skb(sk, skb);
 }

[toc] | [prev] | [next] | [standalone]

#1614568

On 04/01/2017 06:17 AM, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.2.88 release.
> There are 4 patches in this series, which will be posted as responses
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue Apr 04 00:00:00 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 89 pass: 89 fail: 0
Qemu test results:
	total: 69 pass: 69 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]

#1614611

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2017-04-01 at 10:24 -0700, Guenter Roeck wrote:
> On 04/01/2017 06:17 AM, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.2.88
> > release.
> > There are 4 patches in this series, which will be posted as
> > responses
> > to this one.  If anyone has any issues with these being applied,
> > please
> > let me know.
> > 
> > Responses should be made by Tue Apr 04 00:00:00 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 89 pass: 89 fail: 0
> Qemu test results:
> 	total: 69 pass: 69 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice
versa.

[toc] | [prev] | [next] | [standalone]

#1614628

[Multipart message — attachments visible in raw view] — view raw

This is the combined diff for 3.2.88-rc1 relative to 3.2.87.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof because fools are so
ingenious.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web