* Re: netdevice notifier and device private data
From: Alexander Aring @ 2018-06-09 15:29 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <32763.1528486664@localhost>
Hi,
On Fri, Jun 08, 2018 at 03:37:44PM -0400, Michael Richardson wrote:
>
> Alexander Aring <aring@mojatatu.com> wrote:
> Alex> I already see code outside who changed tun netdevice to the
> Alex> ARPHRD_6LOWPAN type and I suppose they running into this
> Alex> issue. (Btw: I don't know why somebody wants to changed that
> Alex> type to ARPHRD_6LOWPAN on tun).
>
> so that they can have the kernel do 6lowpan processing, emitting 6lowPAN
> packets into userspace to be transfered into a radio via some proprietary
> interface (including, for instance SLIP over USB cable to Contiki or OpenWSN stack,
> set up to act as radio only)
>
No, the datapath doesn't change. If the user space evaluate the
dev->type (there exists some ioctl() for it) it will assume it has a
6LoWPAN type interface.
A lot of user space software outside will doing interface specific
handling after detect the type. E.g. wireshark will select some dissector
handling.
On a tun interface and switch to 6LoWPAN it will not change much the
dissector view, because both raw IPv6 packets on datapath. For me as
6LoWPAN maintainer it makes no sense to switch to it. Currently
some netdevice notifier will crash (if you a lucky it will not).
Futhermore user space programs e.g. radvd will do 6lowpan specific
handling on 6lowpan dev->type, it will not work either on tun devices.
I know that wpantund from NestLabs do this switch, I am very curious
about the reason but I think they do it because the name is 6LoWPAN. But
wpantund is just a SLIP like protocol with additional radio/foo commands.
---
According to the people who say "I like to have a 6LoWPAN tun device,
that would be nice" - I don't know how this will ever work since 6LoWPAN
header highly depends on MAC header information. Tun devices works
because IP architecture allows a separation from MAC layer. I already
saw protocols at IETF where MAC header information are needed on top of
UDP payload in case of 6LoWPAN. (I talked about that at last netdev in
Montreal).
Bluetooth wanted to add a tun 6lowpan interface and I was curious how
this works. At the end it was a "Bluetooth mapping to ethernet header"
(not as tunnel, as propagated). I was not acking it, because if there
are protocols who needs more information than just what you can map to
ethernet... it will not work. At least it will also not work with IEEE
802.15.4 at all. They was just lucky that Bluetooth and ethernet use the
same mac address length (And I had some questions to the multicast bit
as well).
Tunnel might work to get mac information. But so far 6loWPAN works it is
that you have a L2 underlaying interface and on top (ip link set master)
a raw IPv6 interface which do the adaptation automatically as a protocol
translation (That's why I cannot understand Bluetooth 6LoWPAN use tx
queues on their 6LoWPAN interface, they need to fix the queue in the
underlaying L2 interface).
As an alternative solution I think it should be something done like TAP
like interface per subsystem. I mean NO ETHERTNET, but the ethernet in
TAP interfaces out and replace it with Bluetooth or IEEE 802.15.4.
I might can easily create a simple TAP IEEE 802.15.4 to show what I
mean.
With an IEEE 802.15.4 TAP device and a 6lowpan interface on top you can
realize your use case and pass 802.15.4 L2 frames to device node -> pops
up at 6LoPWAN interface and send IPv6 stuff and you can read on device
node.
I am still in the opinion the L2 TAP like interface is the way to go to
offer such feature.
- Alex
^ permalink raw reply
* Re: general protection fault in __vfs_write
From: syzbot @ 2018-06-09 15:36 UTC (permalink / raw)
To: alexei.starovoitov, ast, daniel, linux-fsdevel, linux-kernel,
netdev, syzkaller-bugs, viro, willy
In-Reply-To: <000000000000973c2c056e0ecddd@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 3a979e8c07e3 Merge tag 'mailbox-v4.18' of git://git.linaro..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11e0c81f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=412e35656a3f7c09
dashboard link: https://syzkaller.appspot.com/bug?extid=7ade6c94abb2774c0fee
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1665abf7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7ade6c94abb2774c0fee@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
bpfilter: read fail -512
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4546 Comm: syz-executor6 Not tainted 4.17.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:file_write_hint include/linux/fs.h:1932 [inline]
RIP: 0010:init_sync_kiocb include/linux/fs.h:1942 [inline]
RIP: 0010:new_sync_write fs/read_write.c:470 [inline]
RIP: 0010:__vfs_write+0x4a6/0x960 fs/read_write.c:487
Code: c1 ea 03 80 3c 02 00 0f 85 1b 04 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 c8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e ec 02 00 00 41 8b 84 24 c8 00
RSP: 0018:ffff8801ae407850 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801cd88f580 RCX: ffffffff81c0d6fb
RDX: 0000000000000019 RSI: ffffffff81c0d70a RDI: 00000000000000c8
RBP: ffff8801ae4079c8 R08: ffff8801d88ee680 R09: fffffbfff130c5d9
R10: ffff8801ae407a10 R11: ffffffff89862ecb R12: 0000000000000000
R13: ffff8801ae4079a0 R14: 0000000000000000 R15: ffff8801ae407a88
FS: 000000000102f940(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5f52ac0518 CR3: 00000001d8d8a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__kernel_write+0x10c/0x380 fs/read_write.c:506
__bpfilter_process_sockopt+0x1d8/0x35b net/bpfilter/bpfilter_kern.c:66
bpfilter_mbox_request+0x4d/0xb0 net/ipv4/bpfilter/sockopt.c:25
bpfilter_ip_get_sockopt+0x6b/0x90 net/ipv4/bpfilter/sockopt.c:42
ip_getsockopt+0x238/0x2a0 net/ipv4/ip_sockglue.c:1563
tcp_getsockopt+0x93/0xe0 net/ipv4/tcp.c:3532
sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:3012
__sys_getsockopt+0x1a5/0x370 net/socket.c:1972
__do_sys_getsockopt net/socket.c:1983 [inline]
__se_sys_getsockopt net/socket.c:1980 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:1980
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4584ea
Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 1d 8f fb ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fa 8e fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:0000000000a3e328 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000a3e350 RCX: 00000000004584ea
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000706f20 R08: 0000000000a3e34c R09: 0000000000004000
R10: 0000000000a3e350 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000706860
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 9a583fc95516c106 ]---
RIP: 0010:file_write_hint include/linux/fs.h:1932 [inline]
RIP: 0010:init_sync_kiocb include/linux/fs.h:1942 [inline]
RIP: 0010:new_sync_write fs/read_write.c:470 [inline]
RIP: 0010:__vfs_write+0x4a6/0x960 fs/read_write.c:487
Code: c1 ea 03 80 3c 02 00 0f 85 1b 04 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 c8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e ec 02 00 00 41 8b 84 24 c8 00
RSP: 0018:ffff8801ae407850 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801cd88f580 RCX: ffffffff81c0d6fb
RDX: 0000000000000019 RSI: ffffffff81c0d70a RDI: 00000000000000c8
RBP: ffff8801ae4079c8 R08: ffff8801d88ee680 R09: fffffbfff130c5d9
R10: ffff8801ae407a10 R11: ffffffff89862ecb R12: 0000000000000000
R13: ffff8801ae4079a0 R14: 0000000000000000 R15: ffff8801ae407a88
FS: 000000000102f940(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5f52ac0518 CR3: 00000001d8d8a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
^ permalink raw reply
* Re: Qualcomm rmnet driver and qmi_wwan
From: Subash Abhinov Kasiviswanathan @ 2018-06-09 17:55 UTC (permalink / raw)
To: Daniele Palmas; +Cc: Bjørn Mork, Dan Williams, netdev
In-Reply-To: <CAGRyCJFo6PAg3-ukZZFDMEAyqHR=N8me-f-SLOzuJq4ibRBwhA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
> thanks, I will test it on Monday.
>
> Just a question for my knowledge: is the new sysfs attribute really
> needed? I mean, is there not any other way to understand from qmi_wwan
> without user intervention that there is the rmnet device attached?
>
> Regards,
> Daniele
>
Hi Daniele
You can check for the rx_handler attached to qmi_wwan dev and see if it
belongs to rmnet. You can use the attached patch for it but it think the
sysfs way might be a bit cleaner.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-qmi_wwan-Allow-packets-to-pass-through-to-rmnet.patch --]
[-- Type: text/x-diff; name=0001-net-qmi_wwan-Allow-packets-to-pass-through-to-rmnet.patch, Size: 3460 bytes --]
From f7a2b90948da47ade1b345eddb37b721f5ab65f4 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Sat, 9 Jun 2018 11:14:22 -0600
Subject: [PATCH] net: qmi_wwan: Allow packets to pass through to rmnet
Pass through mode is to allow packets in MAP format to be passed
on to rmnet if the rmnet rx handler is attached to it.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 4 +++-
drivers/net/usb/qmi_wwan.c | 10 ++++++++++
include/linux/if_rmnet.h | 20 ++++++++++++++++++++
3 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 include/linux/if_rmnet.h
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index 5f4e447..164a18f 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/netlink.h>
#include <linux/netdevice.h>
+#include <linux/if_rmnet.h>
#include "rmnet_config.h"
#include "rmnet_handlers.h"
#include "rmnet_vnd.h"
@@ -48,10 +49,11 @@
[IFLA_RMNET_FLAGS] = { .len = sizeof(struct ifla_rmnet_flags) },
};
-static int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
{
return rcu_access_pointer(real_dev->rx_handler) == rmnet_rx_handler;
}
+EXPORT_SYMBOL(rmnet_is_real_dev_registered);
/* Needs rtnl lock */
static struct rmnet_port*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f52a9be..abdae63 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -22,6 +22,7 @@
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc-wdm.h>
+#include <linux/if_rmnet.h>
/* This driver supports wwan (3G/LTE/?) devices using a vendor
* specific management protocol called Qualcomm MSM Interface (QMI) -
@@ -354,6 +355,10 @@ static ssize_t add_mux_store(struct device *d, struct device_attribute *attr, c
if (kstrtou8(buf, 0, &mux_id))
return -EINVAL;
+ /* rmnet is already attached here */
+ if (rmnet_is_real_dev_registered(to_net_dev(d)))
+ return -EINVAL;
+
/* mux_id [1 - 0x7f] range empirically found */
if (mux_id < 1 || mux_id > 0x7f)
return -EINVAL;
@@ -543,6 +548,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
if (skb->len < dev->net->hard_header_len)
return 0;
+ if (rawip && rmnet_is_real_dev_registered(skb->dev)) {
+ skb->protocol = htons(ETH_P_MAP);
+ return (netif_rx(skb) == NET_RX_SUCCESS);
+ }
+
if (info->flags & QMI_WWAN_FLAG_MUX)
return qmimux_rx_fixup(dev, skb);
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
new file mode 100644
index 0000000..7a7fb96
--- /dev/null
+++ b/include/linux/if_rmnet.h
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ */
+#ifndef _LINUX_IF_RMNET_H_
+#define _LINUX_IF_RMNET_H_
+#include <linux/netdevice.h>
+
+#if defined(CONFIG_RMNET)
+extern int rmnet_is_real_dev_registered(const struct net_device *real_dev);
+#else
+static inline
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+{
+ return 0;
+}
+#endif
+
+#endif /* !(_LINUX_IF_RMNET_H_) */
--
1.9.1
^ permalink raw reply related
* Re: [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-09 19:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
Hi Geert,
Am 10.06.2018 um 02:33 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>
>> Now that ax88796.c exports the ax_NS8390_init() symbol, we can
>> include 8390.h instead of lib8390.c, avoiding duplication of that
>> function and killing a few compile warnings in the bargain.
>>
>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
>
> Thanks for your patch!
>
>
>> --- a/drivers/net/ethernet/8390/xsurf100.c
>> +++ b/drivers/net/ethernet/8390/xsurf100.c
>> @@ -33,8 +33,6 @@
>> #define HW_CHIPID 0x70
>> #define HW_SCRATCH 0x78
>>
>> -#define __NS8390_init ax_NS8390_init
>> -
>> /* force unsigned long back to 'void __iomem *' */
>> #define ax_convert_addr(_a) ((void __force __iomem *)(_a))
>>
>> @@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
>
> This doesn't apply against net-next, which doesn't have reg_write16() (yet?).
Bummer - that's from my experimental ISP1173 probe code, nothing to do
with network code.
I'll redo these patches against net-next (and add a non-static wrapper
for ax_NS8390_init to allow compiling in the driver).
Thanks,
Michael
> Apart from that, your patch looks fine to me.
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: netdevice notifier and device private data
From: Michael Richardson @ 2018-06-09 19:01 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <20180609152921.hqfmprmd4ryttaie@x220t>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Alexander Aring <aring@mojatatu.com> wrote:
> Futhermore user space programs e.g. radvd will do 6lowpan specific
> handling on 6lowpan dev->type, it will not work either on tun
> devices.
> I know that wpantund from NestLabs do this switch, I am very
> curious about the reason but I think they do it because the name
> is 6LoWPAN. But wpantund is just a SLIP like protocol with
> additional radio/foo commands.
How do they change it then, and what does it do?
It totally seems like broken behaviour. Maybe it's not even intentional.
Maybe they are just foobar.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference in sock_poll
From: syzbot @ 2018-06-09 19:57 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1188a05f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
dashboard link: https://syzkaller.appspot.com/bug?extid=344bb0f46d7719cd9483
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12b5841f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4005f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+344bb0f46d7719cd9483@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 1b2931067 P4D 1b2931067 PUD 1d0ae1067 PMD 0
Oops: 0010 [#1] SMP KASAN
CPU: 0 PID: 4493 Comm: syz-executor249 Not tainted 4.17.0+ #92
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b3bd7590 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b2994800 RCX: 1ffffffff10ea8e5
RDX: ffff8801b3bd7ab0 RSI: ffff8801ace8c980 RDI: ffff8801b378d800
RBP: ffff8801b3bd7700 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003677aeb7
R13: ffff8801b3bd7ab0 R14: ffff8801b2994812 R15: ffff8801b2994c58
FS: 00000000018d6880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b2a10000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_poll+0x1d1/0x710 net/socket.c:1156
vfs_poll+0x77/0x2a0 fs/select.c:40
do_pollfd fs/select.c:848 [inline]
do_poll fs/select.c:896 [inline]
do_sys_poll+0x6fd/0x1100 fs/select.c:990
__do_sys_poll fs/select.c:1048 [inline]
__se_sys_poll fs/select.c:1036 [inline]
__x64_sys_poll+0x189/0x510 fs/select.c:1036
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fcc9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc32252d08 EFLAGS: 00000213 ORIG_RAX: 0000000000000007
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcc9
RDX: 0000000000000003 RSI: 0000000000000001 RDI: 0000000020000040
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004015f0
R13: 0000000000401680 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
CR2: 0000000000000000
---[ end trace c755e9b5f9cf1fa4 ]---
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b3bd7590 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b2994800 RCX: 1ffffffff10ea8e5
RDX: ffff8801b3bd7ab0 RSI: ffff8801ace8c980 RDI: ffff8801b378d800
RBP: ffff8801b3bd7700 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003677aeb7
R13: ffff8801b3bd7ab0 R14: ffff8801b2994812 R15: ffff8801b2994c58
FS: 00000000018d6880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b2a10000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Schmitz @ 2018-06-09 20:09 UTC (permalink / raw)
To: Michael Karcher
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher
In-Reply-To: <16480.46.183.103.8.1528535711.webmail@webmail.zedat.fu-berlin.de>
Hi Michael,
Am 09.06.2018 um 21:15 schrieb Michael Karcher:
> Michael Schmitz schrieb:
>> Hi Michael,
>>> actually, the the block_input / block_output functions were the reason I
>>> included the lib8390.c file. Except for xs100_write / xs100_read, they
>>> are
>>> a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
>>> anymore, but did not get around to improve it. I added a customization
>>> point to ax88796 for a custom block_input / block_output, because the
>>> 8390
>>> core already provides that customization point. What I really need is a
>>> customization point just for the 8390-remote-DMA-via-MMIO functions
>>> (i.e.
>>> xs100_write, xs100_read) instead of the whole block transfer core that
>>> also sets up the remote DMA engine and tries to re-initialize the card
>>> in
>>> case of unexplained problems.
>>
>> OK, so essentially change
>>
>> if (ei_local->word16) {
>> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
>> if (count & 0x01)
>> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>>
>> } else {
>> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
>> }
>>
>> to something like
>>
>> if (ax->block_read) {
>> ax->block_read(dev, buf, count);
>> } else if (ei_local->word16) {
>> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
>> if (count & 0x01)
>> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>>
>> } else {
>> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
>> }
>>
>> and populate ax->block_read() and ax_block_write() from platform data,
>> instead of substituting ax_block_input() / ax_block_output() wholesale?
>
> That's basically how I think the whole lib8390.c story should in fact be
> tackled. Less code duplication, no second include of lib8390 and constrain
> xsurf100.c to the pieces that make this piece of hardware unique.
OK, I'll try that.
>> I must be missing something here.
>
> I don't think so.
>
>> Adds one test for
>> ax->block_read on the critical path but we already have the test for
>> ei_local->word16 there. May need rearranging the tests so the majority
>> of ax88796 users isn't impacted.
> Rearranging sounds like a good idea. As I understand, the only valid
> rearrangement is putting it inside the 16-bit branch, because the xs100
> uses 16-bit transfers and needs the extra byte for odd counts. The code
Thanks, I missed that.
> checks word16 at the beginning of xs100_block_output for that. This has
> the advantage of not hurting users of the 8 bit interface, which might be
> the slowest users of the ax88796, but comes at the cost of not being able
> to customize the block_input/block_output for 8-bit users. As this "cost"
> is not a problem now (no one can customize block_input/block_output
> currently), lets put the block_read check into the word16 block. You might
> want to name the member block_read16 instead of just block_read to convey
> the information, that it is only used if word16 is set.
Fair enough - since any block_input/block_output function always needs
to duplicate quite a bit of 8390 control code, this might be easier.
I'll have to ask Adrian to set up something for me to run speed tests on
though, to see any eventual impact of these changes.
Cheers,
Michael
>> Anyway, your code, your call.
> On the other hand: Your polishing, your call. Thank you for your work on
> gettting the code in good shape for merging.
>
> Kind regards,
> Michael Karcher
>
^ permalink raw reply
* Re: WARNING in do_dentry_open
From: Daniel Borkmann @ 2018-06-09 20:41 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Alexei Starovoitov, netdev
Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <92b8621b-cf57-5fe9-23d1-e06b83ee0c78@iogearbox.net>
On 06/08/2018 03:47 PM, Daniel Borkmann wrote:
> On 06/08/2018 03:34 PM, Dmitry Vyukov wrote:
>> On Fri, Jun 8, 2018 at 3:11 PM, syzbot
>> <syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 68abbe729567 Merge branch 'akpm' (patches from Andrew)
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=130146af800000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2e7fcab0f56fdbb330b8
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1591756f800000
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=152236af800000
>>
>> Looking at the reproducer this seems to be related to bpf.
>> +bpf maintainers
>
> Indeed, thanks! Already working on a fix right now.
#syz fix: bpf: implement dummy fops for bpf objects
^ permalink raw reply
* Re: [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: Daniel Borkmann @ 2018-06-09 20:51 UTC (permalink / raw)
To: John Fastabend, edumazet, weiwan, ast; +Cc: netdev
In-Reply-To: <20180608150644.15153.4135.stgit@john-Precision-Tower-5810>
Hi John,
On 06/08/2018 05:06 PM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> * to modify the accept implementation to clone rather then
> * share the ulp context.
> */
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from sock ops programs. The two supported
> sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
> BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
>
> Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
> 'netperf -H [IPv4]'.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Please also add a Fixes tag to this one. Ok to just reply with one.
Thanks,
Daniel
^ permalink raw reply
* Re: [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: John Fastabend @ 2018-06-09 21:53 UTC (permalink / raw)
To: daniel, ast; +Cc: edumazet, weiwan, netdev
In-Reply-To: <20180608150644.15153.4135.stgit@john-Precision-Tower-5810>
On 06/08/2018 08:06 AM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> * to modify the accept implementation to clone rather then
> * share the ulp context.
> */
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from sock ops programs. The two supported
> sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
> BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
>
> Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
> 'netperf -H [IPv4]'.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
^ permalink raw reply
* [PATCH v3 net-next] net:sched: add action inheritdsfield to skbedit
From: Fu, Qiaobin @ 2018-06-09 22:35 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, Michel Machado,
Marcelo Ricardo Leitner, xiyou.wangcong@gmail.com
In-Reply-To: <A371B54E-186D-4747-B4FB-744E201C3FE5@bu.edu>
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
v3:
*Use optional flags, so that it won't break old versions of tc.
*Allow users to set both SKBEDIT_F_PRIORITY and SKBEDIT_F_INHERITDSFIELD flags.
Original idea by Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
Note that the motivation for this patch is found in the following discussion:
https://www.spinics.net/lists/netdev/msg501061.html
---
diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
index fbcfe27a4e6c..6de6071ebed6 100644
--- a/include/uapi/linux/tc_act/tc_skbedit.h
+++ b/include/uapi/linux/tc_act/tc_skbedit.h
@@ -30,6 +30,7 @@
#define SKBEDIT_F_MARK 0x4
#define SKBEDIT_F_PTYPE 0x8
#define SKBEDIT_F_MASK 0x10
+#define SKBEDIT_F_INHERITDSFIELD 0x20
struct tc_skbedit {
tc_gen;
@@ -45,6 +46,7 @@ enum {
TCA_SKBEDIT_PAD,
TCA_SKBEDIT_PTYPE,
TCA_SKBEDIT_MASK,
+ TCA_SKBEDIT_FLAGS,
__TCA_SKBEDIT_MAX
};
#define TCA_SKBEDIT_MAX (__TCA_SKBEDIT_MAX - 1)
diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
index 6138d1d71900..ef479cd37e7b 100644
--- a/net/sched/act_skbedit.c
+++ b/net/sched/act_skbedit.c
@@ -23,6 +23,9 @@
#include <linux/rtnetlink.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
+#include <net/ip.h>
+#include <net/ipv6.h>
+#include <net/dsfield.h>
#include <linux/tc_act/tc_skbedit.h>
#include <net/tc_act/tc_skbedit.h>
@@ -41,6 +44,25 @@ static int tcf_skbedit(struct sk_buff *skb, const struct tc_action *a,
if (d->flags & SKBEDIT_F_PRIORITY)
skb->priority = d->priority;
+ if (d->flags & SKBEDIT_F_INHERITDSFIELD) {
+ int wlen = skb_network_offset(skb);
+
+ switch (tc_skb_protocol(skb)) {
+ case htons(ETH_P_IP):
+ wlen += sizeof(struct iphdr);
+ if (!pskb_may_pull(skb, wlen))
+ goto err;
+ skb->priority = ipv4_get_dsfield(ip_hdr(skb)) >> 2;
+ break;
+
+ case htons(ETH_P_IPV6):
+ wlen += sizeof(struct ipv6hdr);
+ if (!pskb_may_pull(skb, wlen))
+ goto err;
+ skb->priority = ipv6_get_dsfield(ipv6_hdr(skb)) >> 2;
+ break;
+ }
+ }
if (d->flags & SKBEDIT_F_QUEUE_MAPPING &&
skb->dev->real_num_tx_queues > d->queue_mapping)
skb_set_queue_mapping(skb, d->queue_mapping);
@@ -53,6 +75,10 @@ static int tcf_skbedit(struct sk_buff *skb, const struct tc_action *a,
spin_unlock(&d->tcf_lock);
return d->tcf_action;
+
+err:
+ spin_unlock(&d->tcf_lock);
+ return TC_ACT_SHOT;
}
static const struct nla_policy skbedit_policy[TCA_SKBEDIT_MAX + 1] = {
@@ -62,6 +88,7 @@ static const struct nla_policy skbedit_policy[TCA_SKBEDIT_MAX + 1] = {
[TCA_SKBEDIT_MARK] = { .len = sizeof(u32) },
[TCA_SKBEDIT_PTYPE] = { .len = sizeof(u16) },
[TCA_SKBEDIT_MASK] = { .len = sizeof(u32) },
+ [TCA_SKBEDIT_FLAGS] = { .len = sizeof(u64) },
};
static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
@@ -73,6 +100,7 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
struct tc_skbedit *parm;
struct tcf_skbedit *d;
u32 flags = 0, *priority = NULL, *mark = NULL, *mask = NULL;
+ u64 *pure_flags = NULL;
u16 *queue_mapping = NULL, *ptype = NULL;
bool exists = false;
int ret = 0, err;
@@ -114,6 +142,11 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
mask = nla_data(tb[TCA_SKBEDIT_MASK]);
}
+ if (tb[TCA_SKBEDIT_FLAGS] != NULL) {
+ pure_flags = nla_data(tb[TCA_SKBEDIT_FLAGS]);
+ flags |= *pure_flags;
+ }
+
parm = nla_data(tb[TCA_SKBEDIT_PARMS]);
exists = tcf_idr_check(tn, parm->index, a, bind);
^ permalink raw reply related
* BUG: unable to handle kernel paging request in ebt_do_table
From: syzbot @ 2018-06-09 22:47 UTC (permalink / raw)
To: bridge, coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, stephen, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=101c56bf800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
dashboard link: https://syzkaller.appspot.com/bug?extid=93f34882275ae7caf9db
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10bdbebf800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14a8a0cf800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+93f34882275ae7caf9db@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): team0: link is not ready
8021q: adding VLAN 0 to HW filter on device team0
IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
BUG: unable to handle kernel paging request at ffffc9005c3ca003
PGD 1da946067 P4D 1da946067 PUD 0
Oops: 0000 [#1] SMP KASAN
CPU: 0 PID: 4498 Comm: syz-executor667 Not tainted 4.17.0+ #92
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:ebt_do_table+0x1983/0x2140 net/bridge/netfilter/ebtables.c:288
Code: 24 08 48 89 d8 48 89 9d d0 fe ff ff 48 c1 e8 03 42 0f b6 04 38 84 c0
74 08 3c 03 0f 8e 3b 06 00 00 48 8b 85 d0 fe ff ff 31 ff <8b> 18 89 de e8
04 e8 c0 fa 85 db 0f 85 a0 02 00 00 e8 e7 e6 c0 fa
RSP: 0018:ffff8801b2e15c68 EFLAGS: 00010246
RAX: ffffc9005c3ca003 RBX: ffffc9005c3ca003 RCX: ffffc90001e1e000
RDX: 0000000000000000 RSI: ffffffff86b9558c RDI: 0000000000000000
RBP: ffff8801b2e15e38 R08: ffff8801b2588380 R09: ffffed003b5c46d6
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffc90001e1e000
R13: ffffc90001e1a130 R14: ffffc90001e1a090 R15: dffffc0000000000
FS: 00000000006ed880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9005c3ca003 CR3: 00000001b3ba1000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ebt_in_hook+0x65/0x80 net/bridge/netfilter/ebtable_filter.c:63
ebt_out_hook+0x25/0x30 net/bridge/netfilter/ebtable_filter.c:63
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0xc2/0x1c0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK include/linux/netfilter.h:285 [inline]
__br_forward+0x520/0xd90 net/bridge/br_forward.c:113
deliver_clone+0x61/0xc0 net/bridge/br_forward.c:129
maybe_deliver net/bridge/br_forward.c:170 [inline]
br_flood+0x6f3/0x980 net/bridge/br_forward.c:212
br_dev_xmit+0x1121/0x1810 net/bridge/br_device.c:103
__netdev_start_xmit include/linux/netdevice.h:4128 [inline]
netdev_start_xmit include/linux/netdevice.h:4137 [inline]
xmit_one net/core/dev.c:3034 [inline]
dev_hard_start_xmit+0x264/0xc10 net/core/dev.c:3050
__dev_queue_xmit+0x29da/0x3900 net/core/dev.c:3569
dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
neigh_resolve_output+0x679/0xad0 net/core/neighbour.c:1361
neigh_output include/net/neighbour.h:483 [inline]
ip_finish_output2+0xa5f/0x1840 net/ipv4/ip_output.c:229
ip_do_fragment+0x218e/0x2ac0 net/ipv4/ip_output.c:675
ip_fragment.constprop.49+0x179/0x240 net/ipv4/ip_output.c:546
ip_finish_output+0x6cb/0xf80 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
ip_send_skb+0x40/0xe0 net/ipv4/ip_output.c:1435
udp_send_skb.isra.39+0x6b7/0x11d0 net/ipv4/udp.c:824
udp_push_pending_frames+0x5c/0xf0 net/ipv4/udp.c:852
udp_sendmsg+0x17d1/0x3970 net/ipv4/udp.c:1152
udpv6_sendmsg+0x28c8/0x35f0 net/ipv6/udp.c:1200
inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:643
__sys_sendto+0x3d7/0x670 net/socket.c:1821
__do_sys_sendto net/socket.c:1833 [inline]
__se_sys_sendto net/socket.c:1829 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1829
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441af9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 6b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffeebd76c18 EFLAGS: 00000213 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441af9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000004
RBP: 00000000006cd018 R08: 0000000020000180 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000213 R12: 00000000004027f0
R13: 0000000000402880 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
CR2: ffffc9005c3ca003
---[ end trace b04e96b1e335c4f5 ]---
RIP: 0010:ebt_do_table+0x1983/0x2140 net/bridge/netfilter/ebtables.c:288
Code: 24 08 48 89 d8 48 89 9d d0 fe ff ff 48 c1 e8 03 42 0f b6 04 38 84 c0
74 08 3c 03 0f 8e 3b 06 00 00 48 8b 85 d0 fe ff ff 31 ff <8b> 18 89 de e8
04 e8 c0 fa 85 db 0f 85 a0 02 00 00 e8 e7 e6 c0 fa
RSP: 0018:ffff8801b2e15c68 EFLAGS: 00010246
RAX: ffffc9005c3ca003 RBX: ffffc9005c3ca003 RCX: ffffc90001e1e000
RDX: 0000000000000000 RSI: ffffffff86b9558c RDI: 0000000000000000
RBP: ffff8801b2e15e38 R08: ffff8801b2588380 R09: ffffed003b5c46d6
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffc90001e1e000
R13: ffffc90001e1a130 R14: ffffc90001e1a090 R15: dffffc0000000000
FS: 00000000006ed880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9005c3ca003 CR3: 00000001b3ba1000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* WARNING: kmalloc bug in xdp_umem_create
From: syzbot @ 2018-06-09 22:47 UTC (permalink / raw)
To: bjorn.topel, davem, linux-kernel, magnus.karlsson, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
mm/slab_common.c:996
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4537 Comm: syz-executor849 Not tainted 4.17.0+ #92
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
Code: c5 c0 ca d0 88 5d c3 b8 10 00 00 00 48 85 ff 74 f4 83 ef 01 c1 ef 03
0f b6 87 e0 c9 d0 88 eb d8 31 c0 81 e6 00 02 00 00 75 db <0f> 0b 5d c3 48
8b 04 c5 00 ca d0 88 5d c3 66 90 66 2e 0f 1f 84 00
RSP: 0018:ffff8801acc67998 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff877abea2
RDX: 1ffff10035e17ce3 RSI: 0000000000000000 RDI: 0000000001000010
RBP: ffff8801acc67998 R08: ffff8801d91d82c0 R09: ffffed0035e17cd9
R10: ffffed0035e17cd9 R11: ffff8801af0be6cb R12: dffffc0000000000
R13: 0000000020000000 R14: ffff8801af0be6b0 R15: 00000000006080c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc+0x25/0x760 mm/slab.c:3727
kmalloc_array include/linux/slab.h:634 [inline]
kcalloc include/linux/slab.h:645 [inline]
xdp_umem_pin_pages net/xdp/xdp_umem.c:205 [inline]
xdp_umem_reg net/xdp/xdp_umem.c:318 [inline]
xdp_umem_create+0x5c9/0x10f0 net/xdp/xdp_umem.c:349
xsk_setsockopt+0x443/0x550 net/xdp/xsk.c:531
__sys_setsockopt+0x1bd/0x390 net/socket.c:1935
__do_sys_setsockopt net/socket.c:1946 [inline]
__se_sys_setsockopt net/socket.c:1943 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1943
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fce9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffedcafaac8 EFLAGS: 00000213 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fce9
RDX: 0000000000000004 RSI: 000000000000011b RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000018 R09: 00000000004002c8
R10: 0000000020000040 R11: 0000000000000213 R12: 0000000000401610
R13: 00000000004016a0 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v2 iproute2] net:sched: add action inheritdsfield to skbedit
From: Fu, Qiaobin @ 2018-06-09 22:50 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, Michel Machado,
Marcelo Ricardo Leitner, xiyou.wangcong@gmail.com
In-Reply-To: <9D95003C-B770-4178-A0BF-2F121EFDF7F7@bu.edu>
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
v2:
*Use optional flags, so that it won't break old versions of tc.
Original idea by Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
Note that the motivation for this patch is found in the following discussion:
https://www.spinics.net/lists/netdev/msg501061.html
---
diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
index fbcfe27a..6de6071e 100644
--- a/include/uapi/linux/tc_act/tc_skbedit.h
+++ b/include/uapi/linux/tc_act/tc_skbedit.h
@@ -30,6 +30,7 @@
#define SKBEDIT_F_MARK 0x4
#define SKBEDIT_F_PTYPE 0x8
#define SKBEDIT_F_MASK 0x10
+#define SKBEDIT_F_INHERITDSFIELD 0x20
struct tc_skbedit {
tc_gen;
@@ -45,6 +46,7 @@ enum {
TCA_SKBEDIT_PAD,
TCA_SKBEDIT_PTYPE,
TCA_SKBEDIT_MASK,
+ TCA_SKBEDIT_FLAGS,
__TCA_SKBEDIT_MAX
};
#define TCA_SKBEDIT_MAX (__TCA_SKBEDIT_MAX - 1)
diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
index db5c64ca..b7f27f09 100644
--- a/tc/m_skbedit.c
+++ b/tc/m_skbedit.c
@@ -30,16 +30,18 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT]>\n"
+ fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT] [IF]>\n"
"QM = queue_mapping QUEUE_MAPPING\n"
"PM = priority PRIORITY\n"
"MM = mark MARK\n"
"PT = ptype PACKETYPE\n"
+ "IF = inheritdsfield\n"
"PACKETYPE = is one of:\n"
" host, otherhost, broadcast, multicast\n"
"QUEUE_MAPPING = device transmit queue to use\n"
"PRIORITY = classID to assign to priority field\n"
- "MARK = firewall mark to set\n");
+ "MARK = firewall mark to set\n"
+ "note: inheritdsfield maps DS field to skb->priority\n");
}
static void
@@ -60,6 +62,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
unsigned int tmp;
__u16 queue_mapping, ptype;
__u32 flags = 0, priority, mark;
+ __u64 pure_flags = 0;
struct tc_skbedit sel = { 0 };
if (matches(*argv, "skbedit") != 0)
@@ -111,6 +114,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
}
flags |= SKBEDIT_F_PTYPE;
ok++;
+ } else if (matches(*argv, "inheritdsfield") == 0) {
+ pure_flags |= SKBEDIT_F_INHERITDSFIELD;
+ ok++;
} else if (matches(*argv, "help") == 0) {
usage();
} else {
@@ -156,6 +162,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
if (flags & SKBEDIT_F_PTYPE)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PTYPE,
&ptype, sizeof(ptype));
+ if (pure_flags != 0)
+ addattr_l(n, MAX_MSG, TCA_SKBEDIT_FLAGS,
+ &pure_flags, sizeof(pure_flags));
addattr_nest_end(n, tail);
*argc_p = argc;
@@ -171,6 +180,7 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
__u32 *priority;
__u32 *mark;
__u16 *queue_mapping, *ptype;
+ __u64 *flags;
struct tc_skbedit *p = NULL;
if (arg == NULL)
@@ -211,6 +221,11 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
else
fprintf(f, " ptype %d", *ptype);
}
+ if (tb[TCA_SKBEDIT_FLAGS] != NULL) {
+ flags = RTA_DATA(tb[TCA_SKBEDIT_FLAGS]);
+ if (*flags & SKBEDIT_F_INHERITDSFIELD)
+ fprintf(f, "inherit DS field ");
+ }
print_action_control(f, " ", p->action, "");
^ permalink raw reply related
* Re: [PATCH v3 net-next] net:sched: add action inheritdsfield to skbedit
From: Marcelo Ricardo Leitner @ 2018-06-09 22:51 UTC (permalink / raw)
To: Fu, Qiaobin
Cc: davem@davemloft.net, netdev@vger.kernel.org, jhs@mojatatu.com,
Michel Machado, xiyou.wangcong@gmail.com
In-Reply-To: <38C2B0E3-E108-433B-906A-A2D72CEE4CAE@bu.edu>
On Sat, Jun 09, 2018 at 10:35:48PM +0000, Fu, Qiaobin wrote:
...
> @@ -73,6 +100,7 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
> struct tc_skbedit *parm;
> struct tcf_skbedit *d;
> u32 flags = 0, *priority = NULL, *mark = NULL, *mask = NULL;
> + u64 *pure_flags = NULL;
> u16 *queue_mapping = NULL, *ptype = NULL;
> bool exists = false;
> int ret = 0, err;
> @@ -114,6 +142,11 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
> mask = nla_data(tb[TCA_SKBEDIT_MASK]);
> }
>
> + if (tb[TCA_SKBEDIT_FLAGS] != NULL) {
> + pure_flags = nla_data(tb[TCA_SKBEDIT_FLAGS]);
> + flags |= *pure_flags;
It shouldn't allow setting flags other than the expected ones.
> + }
> +
> parm = nla_data(tb[TCA_SKBEDIT_PARMS]);
>
> exists = tcf_idr_check(tn, parm->index, a, bind);
^ permalink raw reply
* Re: BUG: unable to handle kernel paging request in ebt_do_table
From: Florian Westphal @ 2018-06-09 23:54 UTC (permalink / raw)
To: syzbot; +Cc: netdev, netfilter-devel, syzkaller-bugs
In-Reply-To: <0000000000008fa9d0056e3d4bc9@google.com>
fixed via:
#syz dup: WARNING in ebt_do_table
^ permalink raw reply
* Re: [bug] cxgb4: vrf stopped working with cxgb4 card
From: David Ahern @ 2018-06-10 0:47 UTC (permalink / raw)
To: AMG Zollner Robert, ganeshgr; +Cc: netdev
In-Reply-To: <b515a1c7-2cf8-1af8-372d-393420d298b8@cloudmedia.eu>
Ganesh:
On 6/4/18 9:03 AM, AMG Zollner Robert wrote:
> I have noticed that vrf is not working with kernel v4.15.0 but was
> working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
>
> Setup:
> Two metal servers with a T520-cr card each, directly connected without a
> switch in between.
>
> SVR1 only ipfwd SVR2 with vrf
> .----------------------------. .----------------------------------.
> | | | |
> | 192.168.8.1 [ ens2f4]--|---------|--[ens1f4] 192.168.8.2 |
> | 192.168.9.1 [ens2f4d1]--|---------|--<ens1f4d1> 192.168.9.2 VRF=10 |
> `----------------------------' `----------------------------------'
>
> When vrf is not working there are no error messages (dmesg or iproute
> commands), tcpdump on the interface (SVR2.ens1f4d1) enslaved in vrf 10
> shows packets(arp req/reply) coming in and going out, but outgoing
> packets(arp reply) do not reach the other server SVR1.ens2f4d1
>
>
> Bisect:
> Found this commit to be the problem after doing a git bisect between
> v4.13..v4.15:
>
> commit ba581f77df23c8ee70b372966e69cf10bc5453d8
> Author: Ganesh Goudar <ganeshgr@chelsio.com>
> Date: Sat Sep 23 16:07:28 2017 +0530
>
> cxgb4: do DCB state reset in couple of places
>
> reset the driver's DCB state in couple of places
> where it was missing.
Are you working on a fix for this or should a revert of the above patch
be sent?
>
>
> A bisect step was considered good when:
> - successful ping from SVR1 to SVR2.ens1f4d1 vrf interface
> - successful ping from SVR2 global to SVR2 vrf interface trough SVR1(l3
> forwarding) (this check was redundant,both tests fail or pass simultaneous)
>
> The problem is still present on recent kernels also, checked v4.16.0 and
> v4.17.rc7
>
> Disabling DCB for the card support fixes the problem ( Compiling kernel
> with "CONFIG_CHELSIO_T4_DCB=n")
>
>
>
> This is my first time reporting a bug to the linux kernel and hope I
> have included the right amount of information. Please let me know if I
> have missed something.
>
>
>
> Thank you,
> Zollner Robert
>
>
> --------
> Logs:
>
> VRF configured using folowing commands:
>
> #!/bin/sh
>
> CHDEV=ens1f4
> VRF=vrf-recv
>
> sysctl -w net.ipv4.tcp_l3mdev_accept=1
> sysctl -w net.ipv4.udp_l3mdev_accept=1
> sysctl -w net.ipv4.conf.all.accept_local=1
>
> ifconfig ${CHDEV} 192.168.8.2/24
> ifconfig ${CHDEV}d1 192.168.9.2/24
>
> ip link add ${VRF} type vrf table 10
> ip link set dev ${VRF} up
>
> ip rule add pref 32765 table local
> ip rule del pref 0
>
> ip route add table 10 unreachable default metric 4278198272
>
> ip link set dev ${CHDEV}d1 master ${VRF}
>
> ip route add table 10 default via 192.168.9.1
> ip route add 192.168.9.0/24 via 192.168.8.1
>
>
>
>
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in sock_poll
From: Tetsuo Handa @ 2018-06-10 1:38 UTC (permalink / raw)
To: syzbot, ubraun, linux-s390; +Cc: davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <00000000000080d9a6056e3aeb35@google.com>
On 2018/06/10 4:57, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1188a05f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> dashboard link: https://syzkaller.appspot.com/bug?extid=344bb0f46d7719cd9483
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12b5841f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4005f800000
This is a same report except s/epoll/poll/ .
----------
#include <sys/socket.h>
#include <sys/poll.h>
#define PF_SMC 43
int main(int argc, char *argv[])
{
int sfd = socket(PF_SMC, SOCK_STREAM, 0);
struct pollfd pfd = { .fd = sfd };
poll(&pfd, 1, 0);
return 0;
}
----------
#syz dup: BUG: unable to handle kernel NULL pointer dereference in corrupted
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Tetsuo Handa @ 2018-06-10 2:48 UTC (permalink / raw)
To: syzbot, bjorn.topel, magnus.karlsson
Cc: davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <00000000000092de58056e3d4b96@google.com>
On 2018/06/10 7:47, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> Kernel panic - not syncing: panic_on_warn set ...
syzbot gave up upon kmalloc(), but actually error handling path has
NULL pointer dereference bug.
----------
#include <sys/socket.h>
#include <unistd.h>
#define PF_XDP 44
#define SOL_XDP 283
#define XDP_UMEM_REG 4
int main(int argc, char *argv[])
{
int fd = socket(PF_XDP, SOCK_RAW, 0);
struct xdp_umem_reg {
unsigned long long addr;
unsigned long long len;
unsigned int chunk_size;
unsigned int headroom;
} arg = {
0x20000000,
0x200002000,
0x800,
2
};
setsockopt(fd, SOL_XDP, XDP_UMEM_REG, &arg, sizeof(arg));
return 0;
}
----------
[ 95.172962] WARNING: CPU: 3 PID: 2891 at mm/page_alloc.c:4065 __alloc_pages_nodemask+0x283/0xdf0
[ 95.175179] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
[ 95.180614] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Not tainted 4.17.0+ #421
[ 95.182351] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 95.184909] RIP: 0010:__alloc_pages_nodemask+0x283/0xdf0
[ 95.186319] Code: 00 00 04 00 41 0f 44 c6 48 3b 5c 24 78 c6 84 24 90 00 00 00 00 0f 85 50 0b 00 00 41 83 fd 0a 76 1d f6 c4 02 0f 85 3b ff ff ff <0f> 0b e9 34 ff ff ff 0f 0b 0f 1f 40 00 e9 10 fe ff ff 0f 0b 89 c2
[ 95.190997] RSP: 0018:ffffc900008efd20 EFLAGS: 00010246
[ 95.192257] RAX: 000000000060c0c0 RBX: 0000000000000000 RCX: ffff88013f7fe920
[ 95.194005] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
[ 95.195697] RBP: 000000000060c0c0 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.197393] R10: 000000000000000d R11: 0000000000000e8c R12: 0000000000000001
[ 95.199084] R13: 000000000000000d R14: 000000000060c0c0 R15: 0000000000000000
[ 95.200735] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.203441] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.205726] CR2: 0000000020000040 CR3: 0000000133e2c006 CR4: 00000000001606e0
[ 95.207743] Call Trace:
[ 95.208427] ? __lock_acquire+0x22a/0x1830
[ 95.209391] ? kmalloc_order+0x15/0x60
[ 95.210266] ? __kmalloc+0x20a/0x210
[ 95.211104] ? xdp_umem_create+0x16e/0x3c0
[ 95.212095] ? xsk_setsockopt+0x153/0x1a0
[ 95.213143] ? __sys_setsockopt+0x67/0xb0
[ 95.214058] ? __x64_sys_setsockopt+0x1b/0x20
[ 95.215040] ? do_syscall_64+0x4f/0x1f0
[ 95.215890] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 95.217079] irq event stamp: 5296
[ 95.217785] hardirqs last enabled at (5295): [<ffffffff810b2a77>] __raw_spin_lock_init+0x17/0x50
[ 95.220381] hardirqs last disabled at (5296): [<ffffffff81800f33>] error_entry+0x73/0xc0
[ 95.222447] softirqs last enabled at (5284): [<ffffffff81a00183>] __do_softirq+0x183/0x204
[ 95.224328] softirqs last disabled at (5277): [<ffffffff81061bcd>] irq_exit+0xcd/0xf0
[ 95.226065] ---[ end trace 75b6f67917663997 ]---
[ 95.227250] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
[ 95.229101] PGD 1342eb067 P4D 1342eb067 PUD 1314a2067 PMD 0
[ 95.230398] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 95.231418] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Tainted: G W 4.17.0+ #421
[ 95.233474] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 95.236636] RIP: 0010:xdp_umem_create+0x228/0x3c0
[ 95.237867] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
[ 95.241945] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
[ 95.243236] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
[ 95.244789] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
[ 95.247382] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.249735] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
[ 95.252391] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
[ 95.255280] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.257918] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.260068] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
[ 95.262535] Call Trace:
[ 95.263900] ? xsk_setsockopt+0x153/0x1a0
[ 95.265495] ? __sys_setsockopt+0x67/0xb0
[ 95.267108] ? __x64_sys_setsockopt+0x1b/0x20
[ 95.269532] ? do_syscall_64+0x4f/0x1f0
[ 95.271474] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 95.273292] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
[ 95.279548] CR2: 0000000000000060
[ 95.281044] ---[ end trace 75b6f67917663998 ]---
[ 95.283132] RIP: 0010:xdp_umem_create+0x228/0x3c0
[ 95.285257] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
[ 95.291487] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
[ 95.293429] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
[ 95.295761] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
[ 95.298072] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.300403] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
[ 95.303699] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
[ 95.306178] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.308645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.310782] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
xdp_umem_create+0x228/0x3c0:
arch_atomic64_sub at arch/x86/include/asm/atomic64_64.h:60
(inlined by) atomic64_sub at include/asm-generic/atomic-instrumented.h:145
(inlined by) atomic_long_sub at include/asm-generic/atomic-long.h:199
(inlined by) xdp_umem_unaccount_pages at net/xdp/xdp_umem.c:135
(inlined by) xdp_umem_reg at net/xdp/xdp_umem.c:334
(inlined by) xdp_umem_create at net/xdp/xdp_umem.c:349
^ permalink raw reply
* [PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
As suggested by Geert, xsurf100.c really does not need to duplicate code
from lib8390.c which is already part of ax88796.c, by including that file.
All we need from lib8390.c in the xsurf100 block output function is one
single function: ax_NS8390_init(). Export this symbol through a wrapper in
ax88796.c (the original __NS8390_init() is a static function) so the
xsurf100 driver can use it.
This is rather a quick band-aid fix to deal with the ugliest code duplication
(including lib8390.c where it really isn't needed). The xsurf100 block_input
and block_output functions are almost exact duplicates of the generic ax88796
functions, and changing those to make use of platform-specific block MMIO
transfer functions would allow all duplicated code to be removed from
xsurf100.c. This will be addressed in a later patch.
Changes from earlier RFC version:
- rebased on net-next so patch 2 applies cleanly
- use a non-static wrapper for ax_NS8390_init() alias __NS8390_init() so
this driver can be compiled in.
Tested on Amiga hardware (elgar).
Cheers,
Michael
^ permalink raw reply
* [PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel, Michael Schmitz
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
Now that ax88796.c exports the ax_NS8390_reinit() symbol, we can
include 8390.h instead of lib8390.c, avoiding duplication of that
function and killing a few compile warnings in the bargain.
Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
driver for Amiga X-Surf 100 Zorro board (m68k)")
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/xsurf100.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/8390/xsurf100.c b/drivers/net/ethernet/8390/xsurf100.c
index e2c9638..1c3e8d1 100644
--- a/drivers/net/ethernet/8390/xsurf100.c
+++ b/drivers/net/ethernet/8390/xsurf100.c
@@ -22,8 +22,6 @@
#define XS100_8390_DATA_WRITE32_BASE 0x0C80
#define XS100_8390_DATA_AREA_SIZE 0x80
-#define __NS8390_init ax_NS8390_init
-
/* force unsigned long back to 'void __iomem *' */
#define ax_convert_addr(_a) ((void __force __iomem *)(_a))
@@ -42,10 +40,11 @@
/* Ensure we have our RCR base value */
#define AX88796_PLATFORM
-static unsigned char version[] =
- "ax88796.c: Copyright 2005,2007 Simtec Electronics\n";
+#define NS8390_CORE
+#include "8390.h"
-#include "lib8390.c"
+/* exported from ax88796.c, especially for our benefit */
+extern void ax_NS8390_reinit(struct net_device *dev);
/* from ne.c */
#define NE_CMD EI_SHIFT(0x00)
@@ -232,7 +231,7 @@ static void xs100_block_output(struct net_device *dev, int count,
if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms */
netdev_warn(dev, "timeout waiting for Tx RDC.\n");
ei_local->reset_8390(dev);
- ax_NS8390_init(dev, 1);
+ ax_NS8390_reinit(dev);
break;
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel, Michael Schmitz
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
The block I/O code for the new X-Surf 100 ax88796 driver needs
ax_NS8390_init() for error fixup in its block_output function.
Export this static function through the ax_NS8390_reinit()
wrapper so we can lose the lib8380.c include in the X-Surf 100
driver.
Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
driver for Amiga X-Surf 100 Zorro board (m68k)")
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/ax88796.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2a0ddec..673d154 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -104,6 +104,13 @@ struct ax_device {
return (struct ax_device *)(ei_local + 1);
}
+void ax_NS8390_reinit(struct net_device *dev)
+{
+ ax_NS8390_init(dev, 1);
+}
+
+EXPORT_SYMBOL_GPL(ax_NS8390_reinit);
+
/*
* ax_initial_check
*
--
1.7.0.4
^ permalink raw reply related
* Re: linux-next: Please add mlx5-next tree
From: Leon Romanovsky @ 2018-06-10 5:40 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Saeed Mahameed, Jason Gunthorpe,
Doug Ledford, David S. Miller, linux-netdev, RDMA mailing list
In-Reply-To: <20180608161945.66f4628f@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Fri, Jun 08, 2018 at 04:19:45PM -0700, Stephen Hemminger wrote:
> On Wed, 6 Jun 2018 22:25:00 +0300
> Leon Romanovsky <leon@kernel.org> wrote:
>
> > Hi Stephen,
> >
> > Can you please add the branch "mlx5-next" from the following tree to the
> > linux-next integration tree?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/
> >
> > The mlx5-next branch is used to send shared pull requests to both netdev
> > and RDMA subsystems and it is worth to have linux-next coverage on it
> > before.
> >
> > Thanks
>
> I would hope all network drivers keep getting review in netdev.
> Don't want a path to upstream that bypasses review.
Me too, this branch/tree is intended for patches AFTER they passed review
in netdev and/or RDMA.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: Please add mlx5-next tree
From: Leon Romanovsky @ 2018-06-10 5:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Saeed Mahameed, Jason Gunthorpe, Doug Ledford, David S. Miller,
linux-netdev, RDMA mailing list
In-Reply-To: <20180608074726.5b3883e2@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Fri, Jun 08, 2018 at 07:47:26AM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> On Wed, 6 Jun 2018 22:25:00 +0300 Leon Romanovsky <leon@kernel.org> wrote:
> >
> > Can you please add the branch "mlx5-next" from the following tree to the
> > linux-next integration tree?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/
> >
> > The mlx5-next branch is used to send shared pull requests to both netdev
> > and RDMA subsystems and it is worth to have linux-next coverage on it
> > before.
>
> I try hard not to add new trees during the merge window, sorry. If I
> forget to add it after -rc1 has been released, please remind me.
Thanks Stephen, I'll do.
>
> --
> Cheers,
> Stephen Rothwell
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* KASAN: slab-out-of-bounds Write in tls_push_record
From: syzbot @ 2018-06-10 6:15 UTC (permalink / raw)
To: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 410feb75de24 Merge tag 'arm64-upstream' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1308a0cf800000
kernel config: https://syzkaller.appspot.com/x/.config?x=7c0dfd1fff57e223
dashboard link: https://syzkaller.appspot.com/bug?extid=5c74af81c547738e1684
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5c74af81c547738e1684@syzkaller.appspotmail.com
RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000020000000 R09: 000000000000001c
R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000015
R13: 00000000004c0d3b R14: 00000000004d07a8 R15: 0000000000000002
==================================================================
BUG: KASAN: slab-out-of-bounds in tls_fill_prepend include/net/tls.h:339
[inline]
BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1023/0x13e0
net/tls/tls_sw.c:240
Write of size 1 at addr ffff8801bae68000 by task syz-executor1/24187
CPU: 1 PID: 24187 Comm: syz-executor1 Not tainted 4.17.0+ #91
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
tls_fill_prepend include/net/tls.h:339 [inline]
tls_push_record+0x1023/0x13e0 net/tls/tls_sw.c:240
tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
tls_push_pending_closed_record+0x10c/0x150 net/tls/tls_main.c:211
tls_complete_pending_work include/net/tls.h:277 [inline]
tls_sk_proto_close+0x8f2/0xad0 net/tls/tls_main.c:263
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:598
sock_close+0x16/0x20 net/socket.c:1174
__fput+0x353/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2478
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4559f9
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb96babace8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000072bec8 RCX: 00000000004559f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bec8
RBP: 000000000072bec8 R08: 0000000000000033 R09: 000000000072bea0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd163d2bff R14: 00007fb96babb9c0 R15: 0000000000000000
Allocated by task 24192:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc+0x14e/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:518 [inline]
rw_copy_check_uvector+0x31e/0x3a0 fs/read_write.c:781
import_iovec+0xc3/0x420 lib/iov_iter.c:1459
vfs_readv+0xe2/0x1a0 fs/read_write.c:984
do_preadv+0x1ba/0x270 fs/read_write.c:1070
__do_sys_preadv fs/read_write.c:1120 [inline]
__se_sys_preadv fs/read_write.c:1115 [inline]
__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 24192:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
import_iovec+0x32e/0x420 lib/iov_iter.c:1463
vfs_readv+0xe2/0x1a0 fs/read_write.c:984
do_preadv+0x1ba/0x270 fs/read_write.c:1070
__do_sys_preadv fs/read_write.c:1120 [inline]
__se_sys_preadv fs/read_write.c:1115 [inline]
__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801bae69f80
which belongs to the cache kmalloc-16384 of size 16384
The buggy address is located 8064 bytes to the left of
16384-byte region [ffff8801bae69f80, ffff8801bae6df80)
The buggy address belongs to the page:
page:ffffea0006eb9a00 count:1 mapcount:0 mapping:ffff8801da802200 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0005e2a408 ffff8801da801c48 ffff8801da802200
raw: 0000000000000000 ffff8801bae69f80 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801bae67f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801bae67f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801bae68000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801bae68080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801bae68100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ 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