* Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire
From: Andrey Konovalov @ 2016-11-03 0:15 UTC (permalink / raw)
To: Andrew Morton, David Decotigny, David S. Miller, Dmitry Ivanov,
Eric Dumazet, Florian Westphal, Greg Rose, Herbert Xu,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev
Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Dmitry Vyukov
In-Reply-To: <CAAeHK+wM9yG3c9AksSyj7jYSY4ujssH+vTuV2nyz=-0enLrB8w@mail.gmail.com>
On Wed, Oct 19, 2016 at 4:13 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Modules linked in:
> CPU: 1 PID: 3933 Comm: syz-executor Not tainted 4.9.0-rc1+ #230
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88006b79d800 task.stack: ffff88006bbc0000
> RIP: 0010:[<ffffffff8120872d>] [<ffffffff8120872d>]
> __lock_acquire+0x12d/0x3450 kernel/locking/lockdep.c:3221
> RSP: 0018:ffff88006bbc7420 EFLAGS: 00010006
> RAX: 0000000000000046 RBX: dffffc0000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000003
> RBP: ffff88006bbc75c0 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: ffffffff85f42240 R12: ffff88006b79d800
> R13: ffffffff84bfe4e0 R14: 0000000000000001 R15: 0000000000000060
> FS: 00007fd9c41cc700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000451f80 CR3: 00000000638f0000 CR4: 00000000000006e0
> Stack:
> 0000000000000000 ffff88006bbc0000 ffff88006bbc8000 0000000000000000
> 0000000000000002 ffff88006b79d800 0000000000000000 ffff88006bbc7f48
> ffffffff852adc60 0000000000000000 ffffffff852adc64 1ffffffff0b40135
> Call Trace:
> [<ffffffff8120c5ae>] lock_acquire+0x17e/0x340 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffffffff83fb6fe1>] mutex_lock_nested+0xb1/0x890 kernel/locking/mutex.c:621
> [<ffffffff82db6fd0>] netlink_dump+0x50/0xac0 net/netlink/af_netlink.c:2067
> [<ffffffff82dba381>] __netlink_dump_start+0x501/0x770
> net/netlink/af_netlink.c:2200
> [<ffffffff82dc35b2>] genl_family_rcv_msg+0xa02/0xc80
> net/netlink/genetlink.c:595
> [<ffffffff82dc39e6>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
> [<ffffffff82dc1a70>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
> [<ffffffff82dc2b98>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
> [<ffffffff82dc0329>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
> [<ffffffff82dc0fb7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:606
> [<ffffffff82b7075c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> [<ffffffff82b709c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff8151c944>] __vfs_write+0x334/0x570 fs/read_write.c:512
> [<ffffffff8152045b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81523d84>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<ffffffff83fc0141>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
> Code: 0f 1f 44 00 00 f6 c4 02 0f 85 24 0a 00 00 44 8b 35 c9 61 8b 03
> 45 85 f6 74 2c 4c 89 fa 48 bb 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
> 3c 1a 00 0f 85 04 2f 00 00 49 81 3f a0 dc 2a 85 41 be 00 00
> RIP [<ffffffff8120872d>] __lock_acquire+0x12d/0x3450
> kernel/locking/lockdep.c:3221
> RSP <ffff88006bbc7420>
> ---[ end trace 685b3c182bf7f25c ]---
>
> The reproducer is attached.
>
> On commit 1a1891d762d6e64daf07b5be4817e3fbb29e3c59 (Oct 18).
(Adding more maintainers)
Still seeing this on 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
^ permalink raw reply
* [PATCH net] dccp: do not release listeners too soon
From: Eric Dumazet @ 2016-11-03 0:14 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Gerrit Renker, David S. Miller, dccp, netdev, Dmitry Vyukov,
Alexander Potapenko, Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <CAAeHK+yZ4WF2eXATVFQbe_SKM-MFzXypA6VjGxwUxYV3_4xT9g@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Andrey Konovalov reported following error while fuzzing with syzkaller :
IPv4: Attempt to release alive inet socket ffff880068e98940
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 3905 Comm: a.out Not tainted 4.9.0-rc3+ #333
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b9e0000 task.stack: ffff880068770000
RIP: 0010:[<ffffffff819ead5f>] [<ffffffff819ead5f>]
selinux_socket_sock_rcv_skb+0xff/0x6a0 security/selinux/hooks.c:4639
RSP: 0018:ffff8800687771c8 EFLAGS: 00010202
RAX: ffff88006b9e0000 RBX: 1ffff1000d0eee3f RCX: 1ffff1000d1d312a
RDX: 1ffff1000d1d31a6 RSI: dffffc0000000000 RDI: 0000000000000010
RBP: ffff880068777360 R08: 0000000000000000 R09: 0000000000000002
R10: dffffc0000000000 R11: 0000000000000006 R12: ffff880068e98940
R13: 0000000000000002 R14: ffff880068777338 R15: 0000000000000000
FS: 00007f00ff760700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020008000 CR3: 000000006a308000 CR4: 00000000000006e0
Stack:
ffff8800687771e0 ffffffff812508a5 ffff8800686f3168 0000000000000007
ffff88006ac8cdfc ffff8800665ea500 0000000041b58ab3 ffffffff847b5480
ffffffff819eac60 ffff88006b9e0860 ffff88006b9e0868 ffff88006b9e07f0
Call Trace:
[<ffffffff819c8dd5>] security_sock_rcv_skb+0x75/0xb0 security/security.c:1317
[<ffffffff82c2a9e7>] sk_filter_trim_cap+0x67/0x10e0 net/core/filter.c:81
[<ffffffff82b81e60>] __sk_receive_skb+0x30/0xa00 net/core/sock.c:460
[<ffffffff838bbf12>] dccp_v4_rcv+0xdb2/0x1910 net/dccp/ipv4.c:873
[<ffffffff83069d22>] ip_local_deliver_finish+0x332/0xad0
net/ipv4/ip_input.c:216
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8306abd2>] ip_local_deliver+0x1c2/0x4b0 net/ipv4/ip_input.c:257
[< inline >] dst_input ./include/net/dst.h:507
[<ffffffff83068500>] ip_rcv_finish+0x750/0x1c40 net/ipv4/ip_input.c:396
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8306b82f>] ip_rcv+0x96f/0x12f0 net/ipv4/ip_input.c:487
[<ffffffff82bd9fb7>] __netif_receive_skb_core+0x1897/0x2a50 net/core/dev.c:4213
[<ffffffff82bdb19a>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4251
[<ffffffff82bdb493>] netif_receive_skb_internal+0x1b3/0x390 net/core/dev.c:4279
[<ffffffff82bdb6b8>] netif_receive_skb+0x48/0x250 net/core/dev.c:4303
[<ffffffff8241fc75>] tun_get_user+0xbd5/0x28a0 drivers/net/tun.c:1308
[<ffffffff82421b5a>] tun_chr_write_iter+0xda/0x190 drivers/net/tun.c:1332
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc02c1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
It turns out DCCP calls __sk_receive_skb(), and this broke when
lookups no longer took a reference on listeners.
Fix this issue by adding a @refcounted parameter to __sk_receive_skb(),
so that sock_put() is used only when needed.
Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 73c6b008f1b7..92b269709b9a 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1596,11 +1596,11 @@ static inline void sock_put(struct sock *sk)
void sock_gen_put(struct sock *sk);
int __sk_receive_skb(struct sock *sk, struct sk_buff *skb, const int nested,
- unsigned int trim_cap);
+ unsigned int trim_cap, bool refcounted);
static inline int sk_receive_skb(struct sock *sk, struct sk_buff *skb,
const int nested)
{
- return __sk_receive_skb(sk, skb, nested, 1);
+ return __sk_receive_skb(sk, skb, nested, 1, true);
}
static inline void sk_tx_queue_set(struct sock *sk, int tx_queue)
diff --git a/net/core/sock.c b/net/core/sock.c
index df171acfe232..5e3ca414357e 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -453,7 +453,7 @@ int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
EXPORT_SYMBOL(sock_queue_rcv_skb);
int __sk_receive_skb(struct sock *sk, struct sk_buff *skb,
- const int nested, unsigned int trim_cap)
+ const int nested, unsigned int trim_cap, bool refcounted)
{
int rc = NET_RX_SUCCESS;
@@ -487,7 +487,8 @@ int __sk_receive_skb(struct sock *sk, struct sk_buff *skb,
bh_unlock_sock(sk);
out:
- sock_put(sk);
+ if (refcounted)
+ sock_put(sk);
return rc;
discard_and_relse:
kfree_skb(skb);
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 345a3aeb8c7e..dff7cfab1da4 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -868,7 +868,7 @@ static int dccp_v4_rcv(struct sk_buff *skb)
goto discard_and_relse;
nf_reset(skb);
- return __sk_receive_skb(sk, skb, 1, dh->dccph_doff * 4);
+ return __sk_receive_skb(sk, skb, 1, dh->dccph_doff * 4, refcounted);
no_dccp_socket:
if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 3828f94b234c..09c4e19aa285 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -738,7 +738,8 @@ static int dccp_v6_rcv(struct sk_buff *skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
- return __sk_receive_skb(sk, skb, 1, dh->dccph_doff * 4) ? -1 : 0;
+ return __sk_receive_skb(sk, skb, 1, dh->dccph_doff * 4,
+ refcounted) ? -1 : 0;
no_dccp_socket:
if (!xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb))
^ permalink raw reply related
* Grant Benefit
From: Mrs Julie Leach @ 2016-11-02 23:21 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach104@gmail.com) for claims
^ permalink raw reply
* [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)
From: Jakub Kicinski @ 2016-11-02 23:47 UTC (permalink / raw)
To: Cong Wang
Cc: Johannes Berg, Linux Kernel Network Developers, LKML,
Catalin Marinas, linux-mm
In-Reply-To: <CAM_iQpV_0gyrJC0U6Qk9VSSaNOphe_0tq5o2kt8-r0UybLU5FA@mail.gmail.com>
On Wed, 2 Nov 2016 13:30:34 -0700, Cong Wang wrote:
> On Tue, Nov 1, 2016 at 11:56 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> > On Tue, 1 Nov 2016 11:32:52 -0700, Cong Wang wrote:
> >> On Tue, Nov 1, 2016 at 10:28 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> >> > unreferenced object 0xffff8807389cba28 (size 128):
> >> > comm "swapper/0", pid 1, jiffies 4294898463 (age 781.332s)
> >> > hex dump (first 32 bytes):
> >> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> >> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> >> > backtrace:
> >> > [<ffffffff85decad8>] kmemleak_alloc+0x28/0x50
> >> > [<ffffffff84771246>] __kmalloc+0x206/0x5a0
> >> > [<ffffffff859e1261>] genl_register_family+0x711/0x11d0
> >> > [<ffffffff888d9524>] netlbl_mgmt_genl_init+0x10/0x12
> >> > [<ffffffff888d91e8>] netlbl_netlink_init+0x9/0x26
> >> > [<ffffffff888d9254>] netlbl_init+0x4f/0x85
> >> > [<ffffffff840022b7>] do_one_initcall+0xb7/0x2a0
> >> > [<ffffffff887f9102>] kernel_init_freeable+0x597/0x636
> >> > [<ffffffff85de7793>] kernel_init+0x13/0x140
> >> > [<ffffffff85e0246a>] ret_from_fork+0x2a/0x40
> >>
> >> Looks like we are missing a kfree(family->attrbuf); on error path,
> >> but it is not related to Johannes' recent patches.
> >>
> >> Could the attached patch help?
> >
> > Still there:
> >
> > unreferenced object 0xffff88073fb204e8 (size 64):
> > comm "swapper/0", pid 1, jiffies 4294898455 (age 88.528s)
> > hex dump (first 32 bytes):
> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > backtrace:
> > [<ffffffff93decbf8>] kmemleak_alloc+0x28/0x50
> > [<ffffffff92771246>] __kmalloc+0x206/0x5a0
> > [<ffffffff939e1471>] genl_register_family+0x921/0x1270
> > [<ffffffff968d0ecf>] genl_init+0x11/0x43
> > [<ffffffff920022b7>] do_one_initcall+0xb7/0x2a0
> > [<ffffffff967f9102>] kernel_init_freeable+0x597/0x636
> > [<ffffffff93de78b3>] kernel_init+0x13/0x140
> > [<ffffffff93e0256a>] ret_from_fork+0x2a/0x40
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > etc.
>
> Interesting, from the size it does look like we are leaking family->attrbuf,
> but I don't see other cases could leak it except the error path I fixed.
>
> Mind doing a quick bisect?
Thanks for looking into this! Bisect led me to the following commit:
commit 56989f6d8568c21257dcec0f5e644d5570ba3281
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon Oct 24 14:40:05 2016 +0200
genetlink: mark families as __ro_after_init
Now genl_register_family() is the only thing (other than the
users themselves, perhaps, but I didn't find any doing that)
writing to the family struct.
In all families that I found, genl_register_family() is only
called from __init functions (some indirectly, in which case
I've add __init annotations to clarifly things), so all can
actually be marked __ro_after_init.
This protects the data structure from accidental corruption.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I realized that kmemleak is not scanning the __ro_after_init section...
Following patch solves the false positives but I wonder if it's the
right/acceptable solution.
--->8----------------------------------------------------------------
diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
index 000e6e91f6a0..841579932c52 100644
--- a/arch/s390/kernel/vmlinux.lds.S
+++ b/arch/s390/kernel/vmlinux.lds.S
@@ -62,9 +62,11 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__start_ro_after_init = .;
+ VMLINUX_SYMBOL(__start_data_ro_after_init) = .;
.data..ro_after_init : {
*(.data..ro_after_init)
}
+ VMLINUX_SYMBOL(__end_data_ro_after_init) = .;
EXCEPTION_TABLE(16)
. = ALIGN(PAGE_SIZE);
__end_ro_after_init = .;
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index af0254c09424..4df64a1fc09e 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -14,6 +14,8 @@
* [_sdata, _edata]: contains .data.* sections, may also contain .rodata.*
* and/or .init.* sections.
* [__start_rodata, __end_rodata]: contains .rodata.* sections
+ * [__start_data_ro_after_init, __end_data_ro_after_init]:
+ * contains data.ro_after_init section
* [__init_begin, __init_end]: contains .init.* sections, but .init.text.*
* may be out of this range on some architectures.
* [_sinittext, _einittext]: contains .init.text.* sections
@@ -31,6 +33,7 @@
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
extern char _sinittext[], _einittext[];
+extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
extern char _end[];
extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
extern char __kprobes_text_start[], __kprobes_text_end[];
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 30747960bc54..71c75fb64945 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -259,7 +259,10 @@
* own by defining an empty RO_AFTER_INIT_DATA.
*/
#ifndef RO_AFTER_INIT_DATA
-#define RO_AFTER_INIT_DATA *(.data..ro_after_init)
+#define RO_AFTER_INIT_DATA \
+ VMLINUX_SYMBOL(__start_data_ro_after_init) = .; \
+ *(.data..ro_after_init) \
+ VMLINUX_SYMBOL(__end_data_ro_after_init) = .;
#endif
/*
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index e5355a5b423f..d1380ed93fdf 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1414,6 +1414,7 @@ static void kmemleak_scan(void)
/* data/bss scanning */
scan_large_block(_sdata, _edata);
scan_large_block(__bss_start, __bss_stop);
+ scan_large_block(__start_data_ro_after_init, __end_data_ro_after_init);
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
^ permalink raw reply related
* Xmas Offer
From: Mrs Julie Leach @ 2016-11-02 22:56 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleach93@gmail.com) for claims.
^ permalink raw reply
* Re: mlx5: ifup failure due to huge allocation
From: Saeed Mahameed @ 2016-11-02 23:30 UTC (permalink / raw)
To: Sebastian Ott
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-kernel
In-Reply-To: <alpine.LFD.2.20.1611021431410.1831@schleppi>
On Wed, Nov 2, 2016 at 3:37 PM, Sebastian Ott <sebott@linux.vnet.ibm.com> wrote:
> Hi,
>
> Ifup on an interface provided by CX4 (MLX5 driver) on s390 fails with:
>
> [ 22.318553] ------------[ cut here ]------------
> [ 22.318564] WARNING: CPU: 1 PID: 399 at mm/page_alloc.c:3421 __alloc_pages_nodemask+0x2ee/0x1298
> [ 22.318568] Modules linked in: mlx4_ib ib_core mlx5_core mlx4_en mlx4_core [...]
> [ 22.318610] CPU: 1 PID: 399 Comm: NetworkManager Not tainted 4.8.0 #13
> [ 22.318614] Hardware name: IBM 2964 N96 704 (LPAR)
> [ 22.318618] task: 00000000dbe1c008 task.stack: 00000000dd9e4000
> [ 22.318622] Krnl PSW : 0704c00180000000 00000000002a427e (__alloc_pages_nodemask+0x2ee/0x1298)
> [ 22.318631] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
> Krnl GPRS: 0000000000000000 0000000000ceb4d4 00000000024080c0 0000000000000001
> [ 22.318640] 00000000002a4204 00000000ffffa410 00000000001fffff 0000000000000001
> [ 22.318644] 00000000024080c0 0000000000000009 0000000000000000 0000000000000000
> [ 22.318648] 00000000ffffa400 000000000088ea30 00000000002a4204 00000000dd9e7060
> [ 22.318660] Krnl Code: 00000000002a4272: a7740592 brc 7,2a4d96
> 00000000002a4276: 92011000 mvi 0(%r1),1
> #00000000002a427a: a7f40001 brc 15,2a427c
> >00000000002a427e: a7f4058c brc 15,2a4d96
> 00000000002a4282: 5830f0b4 l %r3,180(%r15)
> 00000000002a4286: 5030f0ec st %r3,236(%r15)
> 00000000002a428a: 1823 lr %r2,%r3
> 00000000002a428c: a53e0048 llilh %r3,72
> [ 22.318695] Call Trace:
> [ 22.318700] ([<00000000002a4204>] __alloc_pages_nodemask+0x274/0x1298)
> [ 22.318706] ([<000000000030dac0>] alloc_pages_current+0x1c0/0x268)
> [ 22.318712] ([<0000000000135aa6>] s390_dma_alloc+0x6e/0x1e0)
> [ 22.318733] ([<000003ff8015474c>] mlx5_dma_zalloc_coherent_node+0xb4/0xf8 [mlx5_core])
> [ 22.318748] ([<000003ff80154c58>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core])
> [ 22.318765] ([<000003ff8015fe06>] mlx5_cqwq_create+0xf6/0x180 [mlx5_core])
> [ 22.318783] ([<000003ff8016654c>] mlx5e_open_cq+0xac/0x1e0 [mlx5_core])
> [ 22.318802] ([<000003ff801693e6>] mlx5e_open_channels+0xe66/0xeb8 [mlx5_core])
> [ 22.318820] ([<000003ff8016982e>] mlx5e_open_locked+0x8e/0x1e0 [mlx5_core])
> [ 22.318837] ([<000003ff801699c6>] mlx5e_open+0x46/0x68 [mlx5_core])
> [ 22.318844] ([<0000000000748338>] __dev_open+0xa8/0x118)
> [ 22.318848] ([<000000000074867a>] __dev_change_flags+0xc2/0x190)
> [ 22.318853] ([<000000000074877e>] dev_change_flags+0x36/0x78)
> [ 22.318858] ([<000000000075bc8a>] do_setlink+0x332/0xb30)
> [ 22.318862] ([<000000000075de3a>] rtnl_newlink+0x3e2/0x820)
> [ 22.318867] ([<000000000075e46e>] rtnetlink_rcv_msg+0x1f6/0x248)
> [ 22.318873] ([<0000000000782202>] netlink_rcv_skb+0x92/0x108)
> [ 22.318878] ([<000000000075c668>] rtnetlink_rcv+0x48/0x58)
> [ 22.318882] ([<0000000000781ace>] netlink_unicast+0x14e/0x1f0)
> [ 22.318887] ([<0000000000781f82>] netlink_sendmsg+0x32a/0x3b0)
> [ 22.318892] ([<000000000071d502>] sock_sendmsg+0x5a/0x80)
> [ 22.318897] ([<000000000071ed38>] ___sys_sendmsg+0x270/0x2a8)
> [ 22.318901] ([<000000000071fe80>] __sys_sendmsg+0x60/0x90)
> [ 22.318905] ([<00000000007207c6>] SyS_socketcall+0x2be/0x388)
> [ 22.318912] ([<000000000086fcae>] system_call+0xd6/0x270)
> [ 22.318916] 3 locks held by NetworkManager/399:
> [ 22.318920] #0: (rtnl_mutex){+.+.+.}, at: [<000000000075c658>] rtnetlink_rcv+0x38/0x58
> [ 22.318935] #1: (&priv->state_lock){+.+.+.}, at: [<000003ff801699bc>] mlx5e_open+0x3c/0x68 [mlx5_core]
> [ 22.318962] #2: (&priv->alloc_mutex){+.+.+.}, at: [<000003ff801546e0>] mlx5_dma_zalloc_coherent_node+0x48/0xf8 [mlx5_core]
> [ 22.318987] Last Breaking-Event-Address:
> [ 22.318992] [<00000000002a427a>] __alloc_pages_nodemask+0x2ea/0x1298
> [ 22.318996] ---[ end trace d2b54f5a0cd00b89 ]---
> [ 22.319001] mlx5_core 0001:00:00.0: 0001:00:00.0:mlx5_cqwq_create:121:(pid 399): mlx5_buf_alloc_node() failed, -12
> [ 22.320548] mlx5_core 0001:00:00.0 enP1s171: mlx5e_open_locked: mlx5e_open_channels failed, -12
>
>
>
> This fails because the largest possible allocation on s390 is currently 1MB (order 8).
> Would it be possible to add the __GFP_NOWARN flag and try a smaller allocation if the
> big one failed? (The latter change also would make the device usable when it is added
> via hotplug and free memory is scattered).
>
Thanks Sebastian for the detailed report.
We are planing and working on a solution to allocate fragmented
buffers rather than demanding contiguous ones.
Hopefully we will have the solution upstream before 4.10 is released.
and yes __GFP_NOWARN is reasonable, will have it as well, the return
value of mlx5_buf_alloc_node is sufficient in case of an error, the
stack trace is just noise.
-Saeed.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Tom Herbert @ 2016-11-02 23:27 UTC (permalink / raw)
To: Thomas Graf
Cc: Hannes Frederic Sowa, David S. Miller, Alexei Starovoitov,
Daniel Borkmann, roopa, netdev
In-Reply-To: <CACby=p=Vnd96Y0g8xfOfz9j8jDNmhASBYV+yM7Fx7G=H=BSsRQ@mail.gmail.com>
On Wed, Nov 2, 2016 at 3:57 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 1 November 2016 at 17:07, Tom Herbert <tom@herbertland.com> wrote:
>> On the other hand, I'm not really sure how to implement for this level
>> of performance this in LWT+BPF either. It seems like one way to do
>> that would be to create a program each destination and set it each
>> host. As you point out would create a million different programs which
>> doesn't seem manageable. I don't think the BPF map works either since
>> that implies we need a lookup (?). It seems like what we need is one
>> program but allow it to be parameterized with per destination
>> information saved in the route (LWT structure).
>
> Attaching different BPF programs to millions of unique dsts doesn't
> make any sense. That will obivously will never scale and it's not
> supposed to scale. This is meant to be used for prefixes which
> represent a series of endpoints, f.e. all local containers, all
> non-internal traffic, all vpn traffic, etc. I'm also not sure why we
> are talking about ILA here, you have written a native implementation,
> why would you want to solve it with BPF again?
>
We are talking about ILA because you specifically mentioned that in
overview log as a use case: "ILA like uses cases where L3 addresses
are resolved and then routed".
Tom
> If you want to run a single program for all dsts, feel free to run the
> same BPF program for each dst. Nobody is forcing you to attach
> individual programs.
^ permalink raw reply
* Re: [PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter
From: Andrew Lunn @ 2016-11-02 23:05 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <8760o55x9j.fsf@ketchup.i-did-not-set--mail-host-address--so-tickle-me>
> Do you expect to return an error if adjust_link is called with
> phydev->duplex == DUPLEX_UNKNOWN, or, do you expect to fallback to
> unforced duplex when setting such value?
ethtool(1) itself does not allow you to specify "unknown". It only
allows "full" or "half". So passing DUPLEX_UNKNOWN means using the API
directly. The core ethtool code does not sanity check the request, so
will pass on DUPLEX_UNKNOWN to the drivers.
A quick search of the drivers, 99% seem to ignore DUPLEX_UNKNOWN. The
1% is bnx2x, which has:
/* If received a request for an unknown duplex, assume full*/
if (cmd->duplex == DUPLEX_UNKNOWN)
cmd->duplex = DUPLEX_FULL;
I personally would return -EINVAL, since it is unclear what
DUPLEX_UNKNOWN means. It could be argued that falling back to Half is
correct, since failed autoneg generally results in 10/Half. Every
Ethernet can do that, where as a device needs to be 25 years or
younger to support Full :-)
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-02 22:58 UTC (permalink / raw)
To: Roopa Prabhu
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, Tom Herbert,
netdev
In-Reply-To: <5819EC81.90405@cumulusnetworks.com>
On 2 November 2016 at 07:39, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>> diff --git a/net/core/Makefile b/net/core/Makefile
>> index d6508c2..a675fd3 100644
>> --- a/net/core/Makefile
>> +++ b/net/core/Makefile
>> @@ -23,7 +23,7 @@ obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o
>> obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
>> obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
>> obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o
>> -obj-$(CONFIG_LWTUNNEL) += lwtunnel.o
>> +obj-$(CONFIG_LWTUNNEL) += lwtunnel.o lwt_bpf.o
>
> Any reason you want to keep lwt bpf under the main CONFIG_LWTUNNEL infra config ?.
> since it is defined as yet another plug-gable encap function, seems like it will be better under a separate
> CONFIG_LWTUNNEL_BPF or CONFIG_LWT_BPF that depends on CONFIG_LWTUNNEL
The code was so minimal with no additional dependencies that I didn't
see a need for a separate Kconfig. I'm fine adding that in the next
iteration though. No objections.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-02 22:57 UTC (permalink / raw)
To: Tom Herbert
Cc: Hannes Frederic Sowa, David S. Miller, Alexei Starovoitov,
Daniel Borkmann, roopa, netdev
In-Reply-To: <CALx6S37s-pTxgqje9+FgmuvVgSZONGURAmJOemL6pOc6_Oepew@mail.gmail.com>
On 1 November 2016 at 17:07, Tom Herbert <tom@herbertland.com> wrote:
> On the other hand, I'm not really sure how to implement for this level
> of performance this in LWT+BPF either. It seems like one way to do
> that would be to create a program each destination and set it each
> host. As you point out would create a million different programs which
> doesn't seem manageable. I don't think the BPF map works either since
> that implies we need a lookup (?). It seems like what we need is one
> program but allow it to be parameterized with per destination
> information saved in the route (LWT structure).
Attaching different BPF programs to millions of unique dsts doesn't
make any sense. That will obivously will never scale and it's not
supposed to scale. This is meant to be used for prefixes which
represent a series of endpoints, f.e. all local containers, all
non-internal traffic, all vpn traffic, etc. I'm also not sure why we
are talking about ILA here, you have written a native implementation,
why would you want to solve it with BPF again?
If you want to run a single program for all dsts, feel free to run the
same BPF program for each dst. Nobody is forcing you to attach
individual programs.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Thomas Graf @ 2016-11-02 22:54 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, Tom Herbert,
roopa, netdev
In-Reply-To: <3f9e7de1-1e61-2fb5-9529-c46343ac39c9@stressinduktion.org>
On 1 November 2016 at 16:12, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On 01.11.2016 21:59, Thomas Graf wrote:
>>> Dumping and verifying which routes get used might actually already be
>>> quite complex on its own. Thus my fear.
>>
>> We even have an API to query which route is used for a tuple. What
>> else would you like to see?
>
> I am not sure here. Some ideas I had were to allow tcpdump (pf_packet)
> sockets sniff at interfaces and also gather and dump the metadata to
> user space (this would depend on bpf programs only doing the
> modifications in metadata and not in the actual packet).
Not sure I understand. Why does this depend on BPF?
> Or maybe just tracing support (without depending on the eBPF program
> developer to have added debugging in the BPF program).
Absolutely in favour of that.
>> This will be addressed with signing AFAIK.
>
> This sounds a bit unrealistic. Signing lots of small programs can be a
> huge burden to the entity doing the signing (if it is not on the same
> computer). And as far as I understood the programs should be generated
> dynamically?
Right, for generated programs, a hash is a better fit and still sufficient.
>> Would it help if we allow to store the original source used for
>> bytecode generation. What would make it clear which program was used.
>
> I would also be fine with just a strong hash of the bytecode, so the
> program can be identified accurately. Maybe helps with deduplication
> later on, too. ;)
OK, I think we all already agreed on doing this.
> Even though I read through the patchset I am not absolutely sure which
> problem it really solves. Especially because lots of things can be done
> already at the ingress vs. egress interface (I looked at patch 4 but I
> am not sure how realistic they are).
Filtering at egress requires to attach the BPF program to all
potential outgoing interface and then pass every single packet through
the program whereas with LWT BPF, I'm only taking the cost where
actually needed.
>> I also don't see how this could possibly scale if all packets must go
>> through a single BPF program. The overhead will be tremendous if you
>> only want to filter a couple of prefixes.
>
> In case of hash table lookup it should be fast. llvm will probably also
> generate jump table for a few 100 ip addresses, no? Additionally the
> routing table lookup could be not done at all.
Why would I want to accept the overhead if I simply avoid it? Just
parsing the header and doing the hash lookup will add cost, cost for
each packet.
^ permalink raw reply
* Re: [PATCH net-next] net: remove unused argument in checksum unnecessary conversion
From: Tom Herbert @ 2016-11-02 22:49 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Linux Kernel Network Developers, David S. Miller,
Willem de Bruijn
In-Reply-To: <1478117651-24909-1-git-send-email-willemdebruijn.kernel@gmail.com>
On Wed, Nov 2, 2016 at 1:14 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The check argument is never used. This code has not changed since
> the original introduction in d96535a17dbb ("net: Infrastructure for
> checksum unnecessary conversions"). Remove the unused argument and
> update all callers.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> include/linux/netdevice.h | 6 +++---
> include/linux/skbuff.h | 8 +++-----
> net/ipv4/gre_demux.c | 3 +--
> net/ipv4/gre_offload.c | 2 +-
> net/ipv4/udp.c | 2 +-
> net/ipv4/udp_offload.c | 2 +-
> net/ipv6/udp.c | 2 +-
> net/ipv6/udp_offload.c | 2 +-
> 8 files changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 66fd61c..ede9e45 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2582,16 +2582,16 @@ static inline bool __skb_gro_checksum_convert_check(struct sk_buff *skb)
> }
>
> static inline void __skb_gro_checksum_convert(struct sk_buff *skb,
> - __sum16 check, __wsum pseudo)
> + __wsum pseudo)
> {
> NAPI_GRO_CB(skb)->csum = ~pseudo;
> NAPI_GRO_CB(skb)->csum_valid = 1;
> }
>
> -#define skb_gro_checksum_try_convert(skb, proto, check, compute_pseudo) \
> +#define skb_gro_checksum_try_convert(skb, proto, compute_pseudo) \
> do { \
> if (__skb_gro_checksum_convert_check(skb)) \
> - __skb_gro_checksum_convert(skb, check, \
> + __skb_gro_checksum_convert(skb, \
> compute_pseudo(skb, proto)); \
> } while (0)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index cc6e23e..e138591 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3492,18 +3492,16 @@ static inline bool __skb_checksum_convert_check(struct sk_buff *skb)
> skb->csum_valid && !skb->csum_bad);
> }
>
> -static inline void __skb_checksum_convert(struct sk_buff *skb,
> - __sum16 check, __wsum pseudo)
> +static inline void __skb_checksum_convert(struct sk_buff *skb, __wsum pseudo)
> {
> skb->csum = ~pseudo;
> skb->ip_summed = CHECKSUM_COMPLETE;
> }
>
> -#define skb_checksum_try_convert(skb, proto, check, compute_pseudo) \
> +#define skb_checksum_try_convert(skb, proto, compute_pseudo) \
> do { \
> if (__skb_checksum_convert_check(skb)) \
> - __skb_checksum_convert(skb, check, \
> - compute_pseudo(skb, proto)); \
> + __skb_checksum_convert(skb, compute_pseudo(skb, proto));\
> } while (0)
>
> static inline void skb_remcsum_adjust_partial(struct sk_buff *skb, void *ptr,
> diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
> index b798862..05eecf0 100644
> --- a/net/ipv4/gre_demux.c
> +++ b/net/ipv4/gre_demux.c
> @@ -91,8 +91,7 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
> return -EINVAL;
> }
>
> - skb_checksum_try_convert(skb, IPPROTO_GRE, 0,
> - null_compute_pseudo);
> + skb_checksum_try_convert(skb, IPPROTO_GRE, null_compute_pseudo);
> options++;
> }
>
> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
> index d5cac99..600ecd7 100644
> --- a/net/ipv4/gre_offload.c
> +++ b/net/ipv4/gre_offload.c
> @@ -190,7 +190,7 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
> if (skb_gro_checksum_simple_validate(skb))
> goto out_unlock;
>
> - skb_gro_checksum_try_convert(skb, IPPROTO_GRE, 0,
> + skb_gro_checksum_try_convert(skb, IPPROTO_GRE,
> null_compute_pseudo);
> }
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 195992e..48bad11 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1869,7 +1869,7 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
> int ret;
>
> if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
> - skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
> + skb_checksum_try_convert(skb, IPPROTO_UDP,
> inet_compute_pseudo);
>
> ret = udp_queue_rcv_skb(sk, skb);
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index b2be1d9..96c2b44 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -321,7 +321,7 @@ static struct sk_buff **udp4_gro_receive(struct sk_buff **head,
> inet_gro_compute_pseudo))
> goto flush;
> else if (uh->check)
> - skb_gro_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
> + skb_gro_checksum_try_convert(skb, IPPROTO_UDP,
> inet_gro_compute_pseudo);
> skip:
> NAPI_GRO_CB(skb)->is_ipv6 = 0;
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index a7700bb..bf3e703 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -804,7 +804,7 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
> }
>
> if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
> - skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
> + skb_checksum_try_convert(skb, IPPROTO_UDP,
> ip6_compute_pseudo);
>
> ret = udpv6_queue_rcv_skb(sk, skb);
> diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
> index ac858c4..6df7be0 100644
> --- a/net/ipv6/udp_offload.c
> +++ b/net/ipv6/udp_offload.c
> @@ -135,7 +135,7 @@ static struct sk_buff **udp6_gro_receive(struct sk_buff **head,
> ip6_gro_compute_pseudo))
> goto flush;
> else if (uh->check)
> - skb_gro_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
> + skb_gro_checksum_try_convert(skb, IPPROTO_UDP,
> ip6_gro_compute_pseudo);
>
> skip:
> --
> 2.8.0.rc3.226.g39d4020
>
Acked-by: Tom Herbert <tom@herbertland.com>
^ permalink raw reply
* Re: net/sctp: use-after-free in __sctp_connect
From: Andrey Konovalov @ 2016-11-02 22:42 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Eric Dumazet, Dmitry Vyukov
In-Reply-To: <20161019165754.GD2958@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Wed, Oct 19, 2016 at 6:57 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Oct 19, 2016 at 02:25:24PM +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in __sctp_connect+0xabe/0xbf0 at addr
>> ffff88006b1dc610
>
> Seems this is the same that Dmitry Vyukov had reported back in Jan 13th.
> So far I couldn't identify the reason.
> "Good" to know it's still there, thanks for reporting it.
Hi Marcelo,
I've attached a reproducer that might help to figure out the reason.
It triggers the UAF for me in ~10 seconds of running as:
$ gcc -lpthread sctp-connect-uaf-poc.c
$ while true; do ./a.out; done
You need to have KASAN enabled.
>
[-- Attachment #2: sctp-connect-uaf-poc.c --]
[-- Type: application/octet-stream, Size: 3735 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_setsockopt
#define __NR_setsockopt 54
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_shutdown
#define __NR_shutdown 48
#endif
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <errno.h>
#include <error.h>
#include <fcntl.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
}
}
long r[14];
void* thr(void* arg)
{
switch ((long)arg) {
case 0:
r[0] =
execute_syscall(__NR_mmap, 0x20000000ul, 0x332000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
break;
case 1:
r[1] = execute_syscall(__NR_socket, 0x2ul, 0x1ul, 0x0ul, 0, 0, 0, 0,
0, 0);
break;
case 2:
r[2] = execute_syscall(__NR_socket, 0xaul, 0x1ul, 0x84ul, 0, 0, 0,
0, 0, 0);
break;
case 3:
r[3] = execute_syscall(__NR_shutdown, r[2], 0x0ul, 0, 0, 0, 0, 0, 0,
0);
break;
case 4:
NONFAILING(*(uint16_t*)0x20008fe4 = (uint16_t)0xa);
NONFAILING(*(uint16_t*)0x20008fe6 = (uint16_t)0x4242);
NONFAILING(*(uint32_t*)0x20008fe8 = (uint32_t)0x1ddb);
NONFAILING(*(uint32_t*)0x20008fec = (uint32_t)0x5);
NONFAILING(*(uint32_t*)0x20008ff0 = (uint32_t)0xffff);
NONFAILING(*(uint32_t*)0x20008ff4 = (uint32_t)0x7);
NONFAILING(*(uint32_t*)0x20008ff8 = (uint32_t)0x0);
NONFAILING(*(uint32_t*)0x20008ffc = (uint32_t)0xffffffffffffff23);
r[12] = execute_syscall(__NR_setsockopt, r[2], 0x84ul, 0x6eul,
0x20008fe4ul, 0x1cul, 0, 0, 0, 0);
break;
case 5:
r[13] = execute_syscall(__NR_shutdown, r[2], 0x1ul, 0, 0, 0, 0, 0,
0, 0);
break;
}
return 0;
}
int main()
{
long i;
pthread_t th[12];
install_segv_handler();
memset(r, -1, sizeof(r));
srand(getpid());
for (i = 0; i < 6; i++) {
pthread_create(&th[i], 0, thr, (void*)i);
usleep(10000);
}
for (i = 0; i < 6; i++) {
pthread_create(&th[6 + i], 0, thr, (void*)i);
if (rand() % 2)
usleep(rand() % 10000);
}
usleep(100000);
return 0;
}
^ permalink raw reply
* Re: [PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter
From: Vivien Didelot @ 2016-11-02 22:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20161102091629.GA384@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> On Wed, Nov 02, 2016 at 02:07:09AM +0100, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>> >> +#define LINK_UNKNOWN -1
>> >> +
>> >> + /* Port's MAC link state
>> >> + * LINK_UNKNOWN for normal link detection, 0 to force link down,
>> >> + * otherwise force link up.
>> >> + */
>> >> + int (*port_set_link)(struct mv88e6xxx_chip *chip, int port, int link);
>> >
>> > Maybe LINK_AUTO would be better than UNKNOWN? Or LINK_UNFORCED.
>>
>> I used LINK_UNKNOWN to be consistent with the supported SPEED_UNKNOWN
>> and DUPLEX_UNKNOWN values of PHY devices.
>
> These are i think for reporting back to user space what duplex or link
> is currently being used. But here you are setting, not
> reporting. Setting something to an unknown state is rather odd, and in
> fact, it is not unknown, it is unforced.
Do you expect to return an error if adjust_link is called with
phydev->duplex == DUPLEX_UNKNOWN, or, do you expect to fallback to
unforced duplex when setting such value?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net] tcp: fix return value for partial writes
From: Soheil Hassas Yeganeh @ 2016-11-02 21:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Willem de Bruijn, Yuchung Cheng,
Neal Cardwell
In-Reply-To: <1478122910.7065.396.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Nov 2, 2016 at 5:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> After my commit, tcp_sendmsg() might restart its loop after
> processing socket backlog.
>
> If sk_err is set, we blindly return an error, even though we
> copied data to user space before.
>
> We should instead return number of bytes that could be copied,
> otherwise user space might resend data and corrupt the stream.
>
> This might happen if another thread is using recvmsg(MSG_ERRQUEUE)
> to process timestamps.
>
> Issue was diagnosed by Soheil and Willem, big kudos to them !
>
> Fixes: d41a69f1d390f ("tcp: make tcp_sendmsg() aware of socket backlog")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
Tested-by: Soheil Hassas Yeganeh <soheil@google.com>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 3251fe71f39f..19e1468bf8ea 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1164,7 +1164,7 @@ int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>
> err = -EPIPE;
> if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
> - goto out_err;
> + goto do_error;
>
> sg = !!(sk->sk_route_caps & NETIF_F_SG);
>
>
>
Nice fix. Thanks, Eric!
^ permalink raw reply
* Re: [PATCH] e1000e: free IRQ when the link is up or down
From: Alexander Duyck @ 2016-11-02 21:44 UTC (permalink / raw)
To: Tyler Baicar
Cc: Jeff Kirsher, intel-wired-lan, Netdev,
linux-kernel@vger.kernel.org, okaya, timur
In-Reply-To: <1478120896-5907-1-git-send-email-tbaicar@codeaurora.org>
On Wed, Nov 2, 2016 at 2:08 PM, Tyler Baicar <tbaicar@codeaurora.org> wrote:
> Move IRQ free code so that it will happen regardless of the
> link state. Currently the e1000e driver only releases its IRQ
> if the link is up. This is not sufficient because it is
> possible for a link to go down without releasing the IRQ. A
> secondary bus reset can cause this case to happen.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 7017281..36cfcb0 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>
> if (!test_bit(__E1000_DOWN, &adapter->state)) {
> e1000e_down(adapter, true);
> - e1000_free_irq(adapter);
>
> /* Link status message must follow this format */
> pr_info("%s NIC Link is Down\n", adapter->netdev->name);
> }
>
> + e1000_free_irq(adapter);
> +
> napi_disable(&adapter->napi);
>
> e1000e_free_tx_resources(adapter->tx_ring);
The __E1000_DOWN bit has nothing to do with link state. It is
basically there to make sure that we don't call e1000e_down multiple
times on the same interface.
With that being said the change itself is probably okay since from
what I can tell e1000e_open doesn't do a check on the __E1000_DOWN bit
before requesting the interrupt. However, you may want to incorporate
pieces of this change (http://patchwork.ozlabs.org/patch/690139/) that
went in for ixgbevf. Basically you need to keep the suspend code from
racing with the close call. The easiest way to do that is to wrap the
bits that are also in e1000e_close in the rtnl_lock like we did for
ixgbevf, and then you would need to check for netif_device_present
before calling e1000_free_irq() just so you didn't call it twice.
- Alex
^ permalink raw reply
* [PATCH net] tcp: fix return value for partial writes
From: Eric Dumazet @ 2016-11-02 21:41 UTC (permalink / raw)
To: David Miller
Cc: netdev, Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Neal Cardwell
From: Eric Dumazet <edumazet@google.com>
After my commit, tcp_sendmsg() might restart its loop after
processing socket backlog.
If sk_err is set, we blindly return an error, even though we
copied data to user space before.
We should instead return number of bytes that could be copied,
otherwise user space might resend data and corrupt the stream.
This might happen if another thread is using recvmsg(MSG_ERRQUEUE)
to process timestamps.
Issue was diagnosed by Soheil and Willem, big kudos to them !
Fixes: d41a69f1d390f ("tcp: make tcp_sendmsg() aware of socket backlog")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3251fe71f39f..19e1468bf8ea 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1164,7 +1164,7 @@ int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
err = -EPIPE;
if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
- goto out_err;
+ goto do_error;
sg = !!(sk->sk_route_caps & NETIF_F_SG);
^ permalink raw reply related
* Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type
From: Brian King @ 2016-11-02 21:40 UTC (permalink / raw)
To: Eric Dumazet, Jon Maxwell
Cc: tlfalcon, jmaxwell, hofrat, linux-kernel, jarod, netdev, paulus,
tom, mleitner, linuxppc-dev, davem
In-Reply-To: <1477582016.7065.212.camel@edumazet-glaptop3.roam.corp.google.com>
On 10/27/2016 10:26 AM, Eric Dumazet wrote:
> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>> We recently encountered a bug where a few customers using ibmveth on the
>> same LPAR hit an issue where a TCP session hung when large receive was
>> enabled. Closer analysis revealed that the session was stuck because the
>> one side was advertising a zero window repeatedly.
>>
>> We narrowed this down to the fact the ibmveth driver did not set gso_size
>> which is translated by TCP into the MSS later up the stack. The MSS is
>> used to calculate the TCP window size and as that was abnormally large,
>> it was calculating a zero window, even although the sockets receive buffer
>> was completely empty.
>>
>> We were able to reproduce this and worked with IBM to fix this. Thanks Tom
>> and Marcelo for all your help and review on this.
>>
>> The patch fixes both our internal reproduction tests and our customers tests.
>>
>> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
>> ---
>> drivers/net/ethernet/ibm/ibmveth.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index 29c05d0..c51717e 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
>> @@ -1182,6 +1182,8 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>> int frames_processed = 0;
>> unsigned long lpar_rc;
>> struct iphdr *iph;
>> + bool large_packet = 0;
>> + u16 hdr_len = ETH_HLEN + sizeof(struct tcphdr);
>>
>> restart_poll:
>> while (frames_processed < budget) {
>> @@ -1236,10 +1238,28 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>> iph->check = 0;
>> iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
>> adapter->rx_large_packets++;
>> + large_packet = 1;
>> }
>> }
>> }
>>
>> + if (skb->len > netdev->mtu) {
>> + iph = (struct iphdr *)skb->data;
>> + if (be16_to_cpu(skb->protocol) == ETH_P_IP &&
>> + iph->protocol == IPPROTO_TCP) {
>> + hdr_len += sizeof(struct iphdr);
>> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
>> + skb_shinfo(skb)->gso_size = netdev->mtu - hdr_len;
>> + } else if (be16_to_cpu(skb->protocol) == ETH_P_IPV6 &&
>> + iph->protocol == IPPROTO_TCP) {
>> + hdr_len += sizeof(struct ipv6hdr);
>> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
>> + skb_shinfo(skb)->gso_size = netdev->mtu - hdr_len;
>> + }
>> + if (!large_packet)
>> + adapter->rx_large_packets++;
>> + }
>> +
>>
>
> This might break forwarding and PMTU discovery.
>
> You force gso_size to device mtu, regardless of real MSS used by the TCP
> sender.
>
> Don't you have the MSS provided in RX descriptor, instead of guessing
> the value ?
We've had some further discussions on this with the Virtual I/O Server (VIOS)
development team. The large receive aggregation in the VIOS (AIX based) is actually
being done by software in the VIOS. What they may be able to do is when performing
this aggregation, they could look at the packet lengths of all the packets being
aggregated and take the largest packet size within the aggregation unit, minus the
header length and return that to the virtual ethernet client which we could then stuff
into gso_size. They are currently assessing how feasible this would be to do and whether
it would impact other bits of the code. However, assuming this does end up being an option,
would this address the concerns here or is that going to break something else I'm
not thinking of?
Unfortunately, I don't think we'd have a good way to get gso_segs set correctly as I don't
see how that would get passed back up the interface.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH net-next iproute2 PATCH 2/2 v2] ss: Add inet raw sockets information gathering via netlink diag interface
From: David Ahern @ 2016-11-02 21:24 UTC (permalink / raw)
To: Cyrill Gorcunov, netdev; +Cc: stephen, avagin
In-Reply-To: <1478092496-7540-3-git-send-email-gorcunov@gmail.com>
On 11/2/16 7:14 AM, Cyrill Gorcunov wrote:
> unix, tcp, udp[lite], packet, netlink sockets already support diag
> interface for their collection and killing. Implement support
> for raw sockets.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> ---
> include/linux/inet_diag.h | 15 +++++++++++++++
> misc/ss.c | 20 ++++++++++++++++++--
> 2 files changed, 33 insertions(+), 2 deletions(-)
worked for me.
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* net/ipv6: null-ptr-deref in inet6_bind
From: Andrey Konovalov @ 2016-11-02 21:14 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]
Hi,
I've got the following error report while running the syzkaller fuzzer:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD 66b6f067 [ 102.549865] PUD 66c6e067
PMD 0 [ 102.549865]
Oops: 0010 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 4143 Comm: a.out Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880066b1c200 task.stack: ffff880065b58000
RIP: 0010:[<0000000000000000>] [< (null)>] (null)
RSP: 0018:ffff880065b5fbc0 EFLAGS: 00010246
RAX: ffff880066b1c200 RBX: ffff88006873864a RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff880068738640 RDI: ffff880063bd3200
RBP: ffff880065b5fd20 R08: 1ffff1000c77a713 R09: dffffc0000000000
R10: ffffffff844fc800 R11: 1ffff1000d0e70c9 R12: ffffffff84e7e040
R13: ffff880068738640 R14: ffff880063bd3200 R15: ffffffff86836380
FS: 00007f40b7acf700(0000) GS:ffff88006cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000006bb28000 CR4: 00000000000006f0
Stack:
ffffffff83099988 ffffffff8479f7e8 ffffffff81208580 1ffff1000000000c
0000000041b58ab3 ffffffff8479f7e8 ffffffff81208580 ffffffff812506ed
0000000000000007 ffff880065b5fc18 ffffffff812506ed ffff880065b5fcd0
Call Trace:
[<ffffffff832cf4fc>] inet6_bind+0x8ec/0x1020 net/ipv6/af_inet6.c:384
[<ffffffff82b7033c>] SYSC_bind+0x1ec/0x250 net/socket.c:1367
[<ffffffff82b72ae4>] SyS_bind+0x24/0x30 net/socket.c:1353
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP <ffff880065b5fbc0>
CR2: 0000000000000000
---[ end trace b5ec698ae4926a97 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt
On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
I'm able to reproduce it with the attached program by running it as:
$ gcc -lpthread inet6-bind-poc.c
$ while true; do ./a.out; done
Thanks!
[-- Attachment #2: inet6-bind-poc.c --]
[-- Type: application/octet-stream, Size: 7394 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_bind
#define __NR_bind 49
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 1000002
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 1000003
#endif
#ifndef __NR_syz_test
#define __NR_syz_test 1000001
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 1000004
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 1000005
#endif
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <errno.h>
#include <error.h>
#include <fcntl.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7)
{
uint64_t target = a0;
uint64_t blkdev = a1;
uint64_t mode = a2;
uint64_t uid = a3;
uint64_t gid = a4;
uint64_t maxread = a5;
uint64_t blksize = a6;
uint64_t flags = a7;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
if (syscall(SYS_mknodat, AT_FDCWD, blkdev, S_IFBLK, makedev(7, 199)))
return fd;
char buf[256];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (blksize != 0)
sprintf(buf + strlen(buf), ",blksize=%ld", (long)blksize);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, blkdev, target, "fuseblk", flags, buf);
return fd;
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
case __NR_syz_test:
return 0;
case __NR_syz_open_dev:
return syz_open_dev(a0, a1, a2);
case __NR_syz_open_pts:
return syz_open_pts(a0, a1);
case __NR_syz_fuse_mount:
return syz_fuse_mount(a0, a1, a2, a3, a4, a5);
case __NR_syz_fuseblk_mount:
return syz_fuseblk_mount(a0, a1, a2, a3, a4, a5, a6, a7);
}
}
long r[21];
void* thr(void* arg)
{
switch ((long)arg) {
case 0:
r[0] =
execute_syscall(__NR_mmap, 0x20000000ul, 0xb88000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
break;
case 1:
r[1] = execute_syscall(__NR_socket, 0xaul, 0x6ul, 0x0ul, 0, 0, 0, 0,
0, 0);
break;
case 2:
r[2] =
execute_syscall(__NR_mmap, 0x20b88000ul, 0x1000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
break;
case 3:
NONFAILING(*(uint16_t*)0x20b88000 = (uint16_t)0xa);
NONFAILING(*(uint16_t*)0x20b88002 = (uint16_t)0x4242);
NONFAILING(*(uint32_t*)0x20b88004 = (uint32_t)0x1);
NONFAILING(*(uint32_t*)0x20b88008 = (uint32_t)0xffffffff);
NONFAILING(*(uint32_t*)0x20b8800c = (uint32_t)0x1);
NONFAILING(*(uint32_t*)0x20b88010 = (uint32_t)0x5);
NONFAILING(*(uint32_t*)0x20b88014 = (uint32_t)0x0);
NONFAILING(*(uint32_t*)0x20b88018 = (uint32_t)0x100000000);
r[11] = execute_syscall(__NR_bind, r[1], 0x20b88000ul, 0x1cul, 0, 0,
0, 0, 0, 0);
break;
case 4:
NONFAILING(*(uint16_t*)0x20000000 = (uint16_t)0xa);
NONFAILING(*(uint16_t*)0x20000002 = (uint16_t)0x4242);
NONFAILING(*(uint32_t*)0x20000004 = (uint32_t)0x400);
NONFAILING(*(uint32_t*)0x20000008 = (uint32_t)0x100000000000000);
NONFAILING(*(uint32_t*)0x2000000c = (uint32_t)0x100000000);
NONFAILING(*(uint32_t*)0x20000010 = (uint32_t)0xffffffffffff0000);
NONFAILING(*(uint32_t*)0x20000014 = (uint32_t)0x0);
NONFAILING(*(uint32_t*)0x20000018 = (uint32_t)0xffff);
r[20] = execute_syscall(__NR_connect, r[1], 0x20000000ul, 0x1cul, 0,
0, 0, 0, 0, 0);
break;
}
return 0;
}
int main()
{
long i;
pthread_t th[10];
install_segv_handler();
memset(r, -1, sizeof(r));
srand(getpid());
for (i = 0; i < 5; i++) {
pthread_create(&th[i], 0, thr, (void*)i);
usleep(10000);
}
for (i = 0; i < 5; i++) {
pthread_create(&th[5 + i], 0, thr, (void*)i);
if (rand() % 2)
usleep(rand() % 10000);
}
usleep(100000);
return 0;
}
^ permalink raw reply
* [PATCH] e1000e: free IRQ when the link is up or down
From: Tyler Baicar @ 2016-11-02 21:08 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, okaya,
timur
Cc: Tyler Baicar
Move IRQ free code so that it will happen regardless of the
link state. Currently the e1000e driver only releases its IRQ
if the link is up. This is not sufficient because it is
possible for a link to go down without releasing the IRQ. A
secondary bus reset can cause this case to happen.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 7017281..36cfcb0 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
if (!test_bit(__E1000_DOWN, &adapter->state)) {
e1000e_down(adapter, true);
- e1000_free_irq(adapter);
/* Link status message must follow this format */
pr_info("%s NIC Link is Down\n", adapter->netdev->name);
}
+ e1000_free_irq(adapter);
+
napi_disable(&adapter->napi);
e1000e_free_tx_resources(adapter->tx_ring);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: [PATCH] net: tcp: check skb is non-NULL for exact match on lookups
From: David Ahern @ 2016-11-02 21:05 UTC (permalink / raw)
To: Andrey Konovalov; +Cc: netdev
In-Reply-To: <CAAeHK+yJ04mjcTkAdiuiWwOB-eG9UhQYZ0iDV5-xH6thmzza6A@mail.gmail.com>
On 11/2/16 2:13 PM, Andrey Konovalov wrote:
> I can confirm that this fixes the null-ptr-deref I've been getting.
>
Thanks, Andrey.
^ permalink raw reply
* net/dccp: null-ptr-deref in dccp_parse_options
From: Andrey Konovalov @ 2016-11-02 20:47 UTC (permalink / raw)
To: Gerrit Renker, David S. Miller, dccp, netdev, LKML
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
Hi,
I've got the following error report while running the syzkaller fuzzer:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 4677 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006ac1d800 task.stack: ffff880067be0000
RIP: 0010:[<ffffffff8389632c>] [< inline >]
ccid_hc_rx_parse_options net/dccp/ccid.h:217
RIP: 0010:[<ffffffff8389632c>] [<ffffffff8389632c>]
dccp_parse_options+0x9dc/0x1010 net/dccp/options.c:218
RSP: 0018:ffff880067be7368 EFLAGS: 00010246
RAX: ffff88006ac1d800 RBX: ffff880066f5807d RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88006bc29bc0
RBP: ffff880067be73f8 R08: 0000000000000000 R09: ffffffff838962fd
R10: ffff88006bc29bc0 R11: 1ffff1000d785474 R12: 0000000000000080
R13: 0000000000000000 R14: dffffc0000000000 R15: ffff880066f5807d
FS: 00007fbc6b0e8700(0000) GS:ffff88006cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004aca30 CR3: 00000000683fa000 CR4: 00000000000006f0
Stack:
ffffffff838909f8 0000000000000000 ffff88006bc2a3a8 ffff88006bc2a3b0
ffffed000d785475 ffff88006abbb900 09ff88006bc2a2f8 ffffffff00000080
ffff88006abbb8c0 ffff88006bc29bc0 0000000000000000 0000000000000000
Call Trace:
[<ffffffff838923f0>] dccp_rcv_state_process+0x200/0x15b0 net/dccp/input.c:644
[<ffffffff838b9cb4>] dccp_v4_do_rcv+0xf4/0x1a0 net/dccp/ipv4.c:681
[< inline >] sk_backlog_rcv ./include/net/sock.h:874
[<ffffffff82b82082>] __sk_receive_skb+0x252/0xa20 net/core/sock.c:479
[<ffffffff838bc027>] dccp_v4_rcv+0xdb7/0x1920 net/dccp/ipv4.c:873
[<ffffffff83069d42>] ip_local_deliver_finish+0x332/0xad0
net/ipv4/ip_input.c:216
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8306abf2>] ip_local_deliver+0x1c2/0x4b0 net/ipv4/ip_input.c:257
[< inline >] dst_input ./include/net/dst.h:507
[<ffffffff83068520>] ip_rcv_finish+0x750/0x1c40 net/ipv4/ip_input.c:396
[< inline >] NF_HOOK_THRESH ./include/linux/netfilter.h:232
[< inline >] NF_HOOK ./include/linux/netfilter.h:255
[<ffffffff8306b84f>] ip_rcv+0x96f/0x12f0 net/ipv4/ip_input.c:487
[<ffffffff82bd9fd7>] __netif_receive_skb_core+0x1897/0x2a50 net/core/dev.c:4213
[<ffffffff82bdb1ba>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4251
[<ffffffff82bdb4b3>] netif_receive_skb_internal+0x1b3/0x390 net/core/dev.c:4279
[<ffffffff82bdb6d8>] netif_receive_skb+0x48/0x250 net/core/dev.c:4303
[<ffffffff8241fc75>] tun_get_user+0xbd5/0x28a0 drivers/net/tun.c:1308
[<ffffffff82421b5a>] tun_chr_write_iter+0xda/0x190 drivers/net/tun.c:1332
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
Code: 49 8d ba e0 07 00 00 49 89 fb 49 c1 eb 03 43 80 3c 33 00 0f 85
59 05 00 00 48 8b 7d b8 4c 8b 87 e0 07 00 00 4c 89 c6 48 c1 ee 03 <42>
80 3c 36 00 0f 85 d5 04 00 00 49 8b 10 48 8d ba 90 00 00 00
RIP [< inline >] ccid_hc_rx_parse_options net/dccp/ccid.h:217
RIP [<ffffffff8389632c>] dccp_parse_options+0x9dc/0x1010 net/dccp/options.c:218
RSP <ffff880067be7368>
---[ end trace f4114105e77749ef ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt
On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
Thanks!
^ permalink raw reply
* [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()
From: Lance Richardson @ 2016-11-02 20:36 UTC (permalink / raw)
To: netdev, fw, jtluka, hannes
Some configurations (e.g. geneve interface with default
MTU of 1500 over an ethernet interface with 1500 MTU) result
in the transmission of packets that exceed the configured MTU.
While this should be considered to be a "bad" configuration,
it is still allowed and should not result in the sending
of packets that exceed the configured MTU.
Fix by dropping the assumption in ip_finish_output_gso() that
locally originated gso packets will never need fragmentation.
Basic testing using iperf (observing CPU usage and bandwidth)
have shown no measurable performance impact for traffic not
requiring fragmentation.
Fixes: c7ba65d7b649 ("net: ip: push gso skb forwarding handling down the stack")
Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
v2: IPSKB_FRAG_SEGS is no longer useful, remove it.
v3: Eliminate unused variable warning.
include/net/ip.h | 3 +--
net/ipv4/ip_forward.c | 2 +-
net/ipv4/ip_output.c | 6 ++----
net/ipv4/ip_tunnel_core.c | 11 -----------
net/ipv4/ipmr.c | 2 +-
5 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 5413883..d3a1078 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -47,8 +47,7 @@ struct inet_skb_parm {
#define IPSKB_REROUTED BIT(4)
#define IPSKB_DOREDIRECT BIT(5)
#define IPSKB_FRAG_PMTU BIT(6)
-#define IPSKB_FRAG_SEGS BIT(7)
-#define IPSKB_L3SLAVE BIT(8)
+#define IPSKB_L3SLAVE BIT(7)
u16 frag_max_size;
};
diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
index 8b4ffd2..9f0a7b9 100644
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -117,7 +117,7 @@ int ip_forward(struct sk_buff *skb)
if (opt->is_strictroute && rt->rt_uses_gateway)
goto sr_failed;
- IPCB(skb)->flags |= IPSKB_FORWARDED | IPSKB_FRAG_SEGS;
+ IPCB(skb)->flags |= IPSKB_FORWARDED;
mtu = ip_dst_mtu_maybe_forward(&rt->dst, true);
if (ip_exceeds_mtu(skb, mtu)) {
IP_INC_STATS(net, IPSTATS_MIB_FRAGFAILS);
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 03e7f73..4971401 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -239,11 +239,9 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,
struct sk_buff *segs;
int ret = 0;
- /* common case: fragmentation of segments is not allowed,
- * or seglen is <= mtu
+ /* common case: seglen is <= mtu
*/
- if (((IPCB(skb)->flags & IPSKB_FRAG_SEGS) == 0) ||
- skb_gso_validate_mtu(skb, mtu))
+ if (skb_gso_validate_mtu(skb, mtu))
return ip_finish_output2(net, sk, skb);
/* Slowpath - GSO segment length is exceeding the dst MTU.
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 777bc18..fed3d29 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -63,7 +63,6 @@ void iptunnel_xmit(struct sock *sk, struct rtable *rt, struct sk_buff *skb,
int pkt_len = skb->len - skb_inner_network_offset(skb);
struct net *net = dev_net(rt->dst.dev);
struct net_device *dev = skb->dev;
- int skb_iif = skb->skb_iif;
struct iphdr *iph;
int err;
@@ -73,16 +72,6 @@ void iptunnel_xmit(struct sock *sk, struct rtable *rt, struct sk_buff *skb,
skb_dst_set(skb, &rt->dst);
memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
- if (skb_iif && !(df & htons(IP_DF))) {
- /* Arrived from an ingress interface, got encapsulated, with
- * fragmentation of encapulating frames allowed.
- * If skb is gso, the resulting encapsulated network segments
- * may exceed dst mtu.
- * Allow IP Fragmentation of segments.
- */
- IPCB(skb)->flags |= IPSKB_FRAG_SEGS;
- }
-
/* Push down and install the IP header. */
skb_push(skb, sizeof(struct iphdr));
skb_reset_network_header(skb);
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 5f006e1..27089f5 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1749,7 +1749,7 @@ static void ipmr_queue_xmit(struct net *net, struct mr_table *mrt,
vif->dev->stats.tx_bytes += skb->len;
}
- IPCB(skb)->flags |= IPSKB_FORWARDED | IPSKB_FRAG_SEGS;
+ IPCB(skb)->flags |= IPSKB_FORWARDED;
/* RFC1584 teaches, that DVMRP/PIM router must deliver packets locally
* not only before forwarding, but after forwarding on all output
--
2.5.5
^ permalink raw reply related
* Re: new kmemleak reports (was: Re: [PATCH 0/5] genetlink improvements)
From: Cong Wang @ 2016-11-02 20:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Johannes Berg, Dmitry Torokhov, Maciej Żenczykowski,
Linux Kernel Network Developers
In-Reply-To: <20161101185630.3c7d326f@jkicinski-Precision-T1700>
On Tue, Nov 1, 2016 at 11:56 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Tue, 1 Nov 2016 11:32:52 -0700, Cong Wang wrote:
>> On Tue, Nov 1, 2016 at 10:28 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
>> > unreferenced object 0xffff8807389cba28 (size 128):
>> > comm "swapper/0", pid 1, jiffies 4294898463 (age 781.332s)
>> > hex dump (first 32 bytes):
>> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>> > backtrace:
>> > [<ffffffff85decad8>] kmemleak_alloc+0x28/0x50
>> > [<ffffffff84771246>] __kmalloc+0x206/0x5a0
>> > [<ffffffff859e1261>] genl_register_family+0x711/0x11d0
>> > [<ffffffff888d9524>] netlbl_mgmt_genl_init+0x10/0x12
>> > [<ffffffff888d91e8>] netlbl_netlink_init+0x9/0x26
>> > [<ffffffff888d9254>] netlbl_init+0x4f/0x85
>> > [<ffffffff840022b7>] do_one_initcall+0xb7/0x2a0
>> > [<ffffffff887f9102>] kernel_init_freeable+0x597/0x636
>> > [<ffffffff85de7793>] kernel_init+0x13/0x140
>> > [<ffffffff85e0246a>] ret_from_fork+0x2a/0x40
>>
>> Looks like we are missing a kfree(family->attrbuf); on error path,
>> but it is not related to Johannes' recent patches.
>>
>> Could the attached patch help?
>>
>> Thanks.
>
> Still there:
>
> unreferenced object 0xffff88073fb204e8 (size 64):
> comm "swapper/0", pid 1, jiffies 4294898455 (age 88.528s)
> hex dump (first 32 bytes):
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> backtrace:
> [<ffffffff93decbf8>] kmemleak_alloc+0x28/0x50
> [<ffffffff92771246>] __kmalloc+0x206/0x5a0
> [<ffffffff939e1471>] genl_register_family+0x921/0x1270
> [<ffffffff968d0ecf>] genl_init+0x11/0x43
> [<ffffffff920022b7>] do_one_initcall+0xb7/0x2a0
> [<ffffffff967f9102>] kernel_init_freeable+0x597/0x636
> [<ffffffff93de78b3>] kernel_init+0x13/0x140
> [<ffffffff93e0256a>] ret_from_fork+0x2a/0x40
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> etc.
Interesting, from the size it does look like we are leaking family->attrbuf,
but I don't see other cases could leak it except the error path I fixed.
Mind doing a quick bisect?
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox