* Re: [PATCH net v2] ipv6: the entire IPv6 header chain must fit the first fragment
From: David Miller @ 2018-03-26 1:18 UTC (permalink / raw)
To: pabeni
Cc: netdev, dsahern, syzbot+91e6f9932ff122fa4410, syzkaller-bugs,
eric.dumazet
In-Reply-To: <43638c155545c57a4b332c64771a1e9b0238148c.1521812678.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 23 Mar 2018 14:47:30 +0100
> While building ipv6 datagram we currently allow arbitrary large
> extheaders, even beyond pmtu size. The syzbot has found a way
> to exploit the above to trigger the following splat:
...
> As stated by RFC 7112 section 5:
>
> When a host fragments an IPv6 datagram, it MUST include the entire
> IPv6 Header Chain in the First Fragment.
>
> So this patch addresses the issue dropping datagrams with excessive
> extheader length. It also updates the error path to report to the
> calling socket nonnegative pmtu values.
>
> The issue apparently predates git history.
>
> v1 -> v2: cleanup error path, as per Eric's suggestion
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+91e6f9932ff122fa4410@syzkaller.appspotmail.com
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net/usb/qmi_wwan.c: Add USB id for lt4120 modem
From: David Miller @ 2018-03-26 1:16 UTC (permalink / raw)
To: torsten.hilbrich; +Cc: bjorn, netdev, linux-usb, Dennis.Wassenberg
In-Reply-To: <1d843b19-6998-f8af-996c-b31f7efb7c1d@secunet.com>
From: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Date: Fri, 23 Mar 2018 14:26:18 +0100
> This is needed to support the modem found in HP EliteBook 820 G3.
>
> Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
This patch was corrupted by your email client, it transformed TAB
characters into sequence of spaces.
Please email the patch to yourself and make sure you can apply
the patch you receive in that email cleanly before resubmitting
it here.
Thank you.
^ permalink raw reply
* Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()
From: David Miller @ 2018-03-26 1:15 UTC (permalink / raw)
To: glider; +Cc: dvyukov, edumazet, netdev, linux-kernel
In-Reply-To: <20180323124902.41625-1-glider@google.com>
From: Alexander Potapenko <glider@google.com>
Date: Fri, 23 Mar 2018 13:49:02 +0100
> KMSAN reports use of uninitialized memory in the case when |alen| is
> smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
> fully copied from the userspace.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
> ---
> v2: fixed a typo spotted by Eric Dumazet
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] ibmvnic: Potential NULL dereference in clean_one_tx_pool()
From: David Miller @ 2018-03-26 1:14 UTC (permalink / raw)
To: dan.carpenter
Cc: benh, tlfalcon, jallen, paulus, mpe, netdev, linuxppc-dev,
kernel-janitors
In-Reply-To: <20180323113615.GA28518@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 23 Mar 2018 14:36:15 +0300
> There is an && vs || typo here, which potentially leads to a NULL
> dereference.
>
> Fixes: e9e1e97884b7 ("ibmvnic: Update TX pool cleaning routine")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: support new ISSI flash parts
From: David Miller @ 2018-03-26 1:09 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, leedom
In-Reply-To: <1521804949-1307-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 23 Mar 2018 17:05:49 +0530
> Add support for new 32MB and 64MB ISSI (Integrated Silicon
> Solution, Inc.) FLASH parts.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: depend on firmware event for link status
From: David Miller @ 2018-03-26 1:08 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, leedom
In-Reply-To: <1521804790-1013-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 23 Mar 2018 17:03:10 +0530
> Depend on the firmware sending us link status changes,
> rather than assuming that the link goes down upon L1
> configuration.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: copy vlan_id in ndo_get_vf_config
From: David Miller @ 2018-03-26 1:08 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1521800326-32568-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 23 Mar 2018 15:48:46 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> Copy vlan_id to get it displayed in vf info.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudhar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH v1 net] lan78xx: Set ASD in MAC_CR when EEE is enabled.
From: David Miller @ 2018-03-26 1:07 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180323101808.6317-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Fri, 23 Mar 2018 15:48:08 +0530
> Description:
> EEE does not work with lan7800 when AutoSpeed is not set.
> (This can happen when EEPROM is not populated or configured incorrectly)
>
> Root-Cause:
> When EEE is enabled, the mac config register ASD is not set
> i.e. in default state, causing EEE fail.
>
> Fix:
> Set the register when eeprom is not present.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
> ---
> v0->v1:
> * Resolved the style related problems.
> * Removed 1/3 patch count from Subject line.
Applied, thanks.
^ permalink raw reply
* Needed your reply as possible for more details
From: Mr Jeremiah Bworo @ 2018-03-26 1:05 UTC (permalink / raw)
Hello dear ,
I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In
Benin Republic as a Principal Director with Federal Ministry Of Works
and Housing here .
I will be delighted to invest with you there in your country into
lucrative investments under your management as far as you could
promise me of your country's economic stability .
I await your response for more close discussions.
Regards,
Mr. Jeremiah Bworo
Principal director
Ministry of Works and Housing
Benin Republic.
^ permalink raw reply
* Re: [PATCH V2 net 1/1] net/ipv4: disable SMC TCP option with SYN Cookies
From: David Miller @ 2018-03-26 0:54 UTC (permalink / raw)
To: ubraun
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, hwippel,
eric.dumazet
In-Reply-To: <20180323100545.78607-2-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Fri, 23 Mar 2018 11:05:45 +0100
> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>
> Currently, the SMC experimental TCP option in a SYN packet is lost on
> the server side when SYN Cookies are active. However, the corresponding
> SYNACK sent back to the client contains the SMC option. This causes an
> inconsistent view of the SMC capabilities on the client and server.
>
> This patch disables the SMC option in the SYNACK when SYN Cookies are
> active to avoid this issue.
>
> Fixes: 60e2a7780793b ("tcp: TCP experimental option for SMC")
> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Setup FW queues before registering netdev
From: David Miller @ 2018-03-26 0:52 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1521798910-31957-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 23 Mar 2018 15:25:10 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> When NetworkManager is enabled, there are chances that interface up
> is called even before probe completes. This means we have not yet
> allocated the FW sge queues, hence rest of ingress queue allocation
> wont be proper. Fix this by calling setup_fw_sge_queues() before
> register_netdev().
>
> Fixes: 0fbc81b3ad51 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's')
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: broadcom: Adaptive interrupt coalescing
From: David Miller @ 2018-03-26 0:49 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jaedon.shin, pgynther, opendmb, michal.chan, gospo, talgi,
saeedm
In-Reply-To: <20180323011933.29748-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 22 Mar 2018 18:19:31 -0700
> This patch series adds adaptive interrupt coalescing for the Gigabit
> Ethernet drivers SYSTEMPORT and GENET.
>
> This really helps lower the interrupt count and system load, as
> measured by vmstat for a Gigabit TCP RX session:
Looks good to me, series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/2] Fixes to allow mv88e6xxx module to be reloaded
From: David Miller @ 2018-03-26 0:43 UTC (permalink / raw)
To: andrew; +Cc: netdev, u.kleine-koenig
In-Reply-To: <1522014195-18671-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 25 Mar 2018 23:43:13 +0200
> As reported by Uwe Kleine-König, the interrupt trigger is first
> configured by DT and then reconfigured to edge. This results in a
> failure on EPROBE_DEFER, or if the module is unloaded and reloaded.
>
> A second crash happens on module reload due to a missing call to the
> common IRQ free code when using polled interrupts.
>
> With these fixes in place, it becomes possible to load and unload the
> kernel modules a few times without it crashing.
>
> v2: Fix the ü in Künig a couple of times
> v3: But the ü should be an ö!
Series applied.
^ permalink raw reply
* general protection fault in tipc_sk_fill_sock_diag
From: syzbot @ 2018-03-26 0:01 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot hit the following crash on net-next commit
94cb5492409219ee3f9468616dd58af314029f76 (Fri Mar 23 18:31:30 2018 +0000)
net/sched: act_vlan: declare push_vid with host byte order
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=326e587eff1074657718
So far this crash happened 8 times on net-next.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5316828523921408
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5398288350052352
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5097949340106752
Kernel config:
https://syzkaller.appspot.com/x/.config?id=2445237949826843652
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+326e587eff1074657718@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
audit: type=1400 audit(1522009585.022:6): avc: denied { map } for
pid=4261 comm="bash" path="/bin/bash" dev="sda1" ino=1457
scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file permissive=1
audit: type=1400 audit(1522009597.461:7): avc: denied { map } for
pid=4277 comm="syzkaller549428" path="/root/syzkaller549428900" dev="sda1"
ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
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
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4277 Comm: syzkaller549428 Not tainted 4.16.0-rc6+ #280
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:sk_user_ns include/net/sock.h:748 [inline]
RIP: 0010:tipc_sk_fill_sock_diag+0x42d/0xc00 net/tipc/socket.c:3282
RSP: 0018:ffff8801b017eff0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 1ffff1003602fe04 RCX: 000000000000002b
RDX: dffffc0000000000 RSI: 1ffff10035d4b577 RDI: 0000000000000158
RBP: ffff8801b017f2a8 R08: 1ffff1003602fdbf R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801d1637740
R13: ffff8801b0d50d40 R14: ffff8801b017f280 R15: 0000000000000000
FS: 00000000014a6880(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020005000 CR3: 00000001b01b3005 CR4: 00000000001606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__tipc_add_sock_diag+0x20e/0x330 net/tipc/diag.c:62
tipc_nl_sk_walk+0x565/0xb60 net/tipc/socket.c:3240
tipc_diag_dump+0x24/0x30 net/tipc/diag.c:73
netlink_dump+0x492/0xcf0 net/netlink/af_netlink.c:2222
__netlink_dump_start+0x4ec/0x710 net/netlink/af_netlink.c:2319
netlink_dump_start include/linux/netlink.h:214 [inline]
tipc_sock_diag_handler_dump+0x206/0x2c0 net/tipc/diag.c:89
__sock_diag_cmd net/core/sock_diag.c:230 [inline]
sock_diag_rcv_msg+0x204/0x360 net/core/sock_diag.c:261
netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2444
sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:272
netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:639
___sys_sendmsg+0x767/0x8b0 net/socket.c:2047
__sys_sendmsg+0xe5/0x210 net/socket.c:2081
SYSC_sendmsg net/socket.c:2092 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2088
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x43fde9
RSP: 002b:00007ffc6f197198 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fde9
RDX: 0000000000000000 RSI: 0000000020005000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401710
R13: 00000000004017a0 R14: 0000000000000000 R15: 0000000000000000
Code: f9 48 c1 e9 03 80 3c 11 00 0f 85 b5 07 00 00 4d 8b 7f 18 48 ba 00 00
00 00 00 fc ff df 49 8d bf 58 01 00 00 48 89 f9 48 c1 e9 03 <80> 3c 11 00
0f 85 2b 07 00 00 4d 8b bf 58 01 00 00 48 ba 00 00
RIP: sk_user_ns include/net/sock.h:748 [inline] RSP: ffff8801b017eff0
RIP: tipc_sk_fill_sock_diag+0x42d/0xc00 net/tipc/socket.c:3282 RSP:
ffff8801b017eff0
---[ end trace ae417c2a60a8b333 ]---
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* possible deadlock in handle_rx
From: syzbot @ 2018-03-26 0:01 UTC (permalink / raw)
To: jasowang, kvm, linux-kernel, mst, netdev, syzkaller-bugs,
virtualization
Hello,
syzbot hit the following crash on upstream commit
cb6416592bc2a8b731dabcec0d63cda270764fc6 (Sun Mar 25 17:45:10 2018 +0000)
Merge tag 'dmaengine-fix-4.16-rc7' of
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=7f073540b1384a614e09
So far this crash happened 4 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6506789075943424
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5716250550337536
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5142038655795200
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7f073540b1384a614e09@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
============================================
WARNING: possible recursive locking detected
4.16.0-rc6+ #366 Not tainted
--------------------------------------------
vhost-4248/4760 is trying to acquire lock:
(&vq->mutex){+.+.}, at: [<000000003482bddc>] vhost_net_rx_peek_head_len
drivers/vhost/net.c:633 [inline]
(&vq->mutex){+.+.}, at: [<000000003482bddc>] handle_rx+0xeb1/0x19c0
drivers/vhost/net.c:784
but task is already holding lock:
(&vq->mutex){+.+.}, at: [<000000004de72f44>] handle_rx+0x1f5/0x19c0
drivers/vhost/net.c:766
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&vq->mutex);
lock(&vq->mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by vhost-4248/4760:
#0: (&vq->mutex){+.+.}, at: [<000000004de72f44>] handle_rx+0x1f5/0x19c0
drivers/vhost/net.c:766
stack backtrace:
CPU: 0 PID: 4760 Comm: vhost-4248 Not tainted 4.16.0-rc6+ #366
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_deadlock_bug kernel/locking/lockdep.c:1761 [inline]
check_deadlock kernel/locking/lockdep.c:1805 [inline]
validate_chain kernel/locking/lockdep.c:2401 [inline]
__lock_acquire+0xe8f/0x3e00 kernel/locking/lockdep.c:3431
lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
vhost_net_rx_peek_head_len drivers/vhost/net.c:633 [inline]
handle_rx+0xeb1/0x19c0 drivers/vhost/net.c:784
handle_rx_net+0x19/0x20 drivers/vhost/net.c:910
vhost_worker+0x268/0x470 drivers/vhost/vhost.c:361
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* BUG: unable to handle kernel paging request in smc_ib_remember_port_attr
From: syzbot @ 2018-03-26 0:01 UTC (permalink / raw)
To: davem, linux-kernel, linux-s390, netdev, syzkaller-bugs, ubraun
Hello,
syzbot hit the following crash on upstream commit
bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +0000)
Merge tag 'pinctrl-v4.16-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=5cd61039dc9b8bfa6e47
So far this crash happened 5 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4566822275776512
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5414431521505280
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5642358322364416
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5cd61039dc9b8bfa6e47@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
BUG: unable to handle kernel paging request at fffffc0000000000
IP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
IP: memory_is_nonzero mm/kasan/kasan.c:184 [inline]
IP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
IP: memory_is_poisoned mm/kasan/kasan.c:241 [inline]
IP: check_memory_region_inline mm/kasan/kasan.c:257 [inline]
IP: check_memory_region+0x83/0x190 mm/kasan/kasan.c:267
PGD 0 P4D 0
Oops: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4138 Comm: syzkaller407129 Not tainted 4.16.0-rc6+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
RIP: 0010:memory_is_nonzero mm/kasan/kasan.c:184 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
RIP: 0010:check_memory_region+0x83/0x190 mm/kasan/kasan.c:267
RSP: 0018:ffff8801b8c472e0 EFLAGS: 00010282
RAX: fffffc0000000000 RBX: 0000000000000017 RCX: ffffffff85a53701
RDX: 0000000000000001 RSI: 0000000000000040 RDI: ffffffffffffffd8
RBP: ffff8801b8c472f0 R08: fffffc0000000001 R09: dffffc0000000003
R10: e000000000000008 R11: dffffc0000000002 R12: dffffc0000000003
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffffffffd8
FS: 0000000000a75880(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffc0000000000 CR3: 00000001ceb8a001 CR4: 00000000001606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
memset+0x23/0x40 mm/kasan/kasan.c:285
memset include/linux/string.h:330 [inline]
smc_ib_remember_port_attr+0x91/0x340 net/smc/smc_ib.c:419
smc_pnet_add+0xb43/0xde0 net/smc/smc_pnet.c:354
genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2444
genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640
___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
__sys_sendmsg+0xe5/0x210 net/socket.c:2080
SYSC_sendmsg net/socket.c:2091 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2087
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x43fda9
RSP: 002b:00007ffd35aa5268 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fda9
RDX: 0000000000040004 RSI: 0000000020a87fc8 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016d0
R13: 0000000000401760 R14: 0000000000000000 R15: 0000000000000000
Code: fa 10 7f 3d 4d 85 d2 74 33 41 80 39 00 75 21 48 b8 01 00 00 00 00 fc
ff df 4d 01 d1 49 01 c0 4d 39 c1 4c 89 c0 74 15 49 83 c0 01 <80> 38 00 74
ef 48 85 c0 49 89 c0 0f 85 89 00 00 00 5b 41 5c 5d
RIP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline] RSP: ffff8801b8c472e0
RIP: memory_is_nonzero mm/kasan/kasan.c:184 [inline] RSP: ffff8801b8c472e0
RIP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline] RSP:
ffff8801b8c472e0
RIP: memory_is_poisoned mm/kasan/kasan.c:241 [inline] RSP: ffff8801b8c472e0
RIP: check_memory_region_inline mm/kasan/kasan.c:257 [inline] RSP:
ffff8801b8c472e0
RIP: check_memory_region+0x83/0x190 mm/kasan/kasan.c:267 RSP:
ffff8801b8c472e0
CR2: fffffc0000000000
---[ end trace 327b8c6e0903b0d7 ]---
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net] r8169: fix setting driver_data after register_netdev
From: Andrew Lunn @ 2018-03-25 23:24 UTC (permalink / raw)
To: Francois Romieu
Cc: Heiner Kallweit, Realtek linux nic maintainers, David Miller,
netdev@vger.kernel.org
In-Reply-To: <20180325230700.GA1735@electric-eye.fr.zoreil.com>
On Mon, Mar 26, 2018 at 01:07:00AM +0200, Francois Romieu wrote:
> Heiner Kallweit <hkallweit1@gmail.com> :
> > pci_set_drvdata() is called only after registering the net_device,
> > therefore we could run into a NPE if one of the functions using
> > driver_data is called before it's set.
> >
> > Fix this by calling pci_set_drvdata() before registering the
> > net_device.
> >
> > This fix is a candidate for stable. As far as I can see the
> > bug has been there in kernel version 3.2 already, therefore
> > I can't provide a reference which commit is fixed by it.
>
> It does not sound convincing.
>
> Please tell which functions are supposed to crash.
How about rtl8169_get_wol() and rtl8169_set_wol(). And
rtl8169_get_ethtool_stats(). Basically anything which makes use of
run time power management could be invoked as soon as parts of
register_netdev() have been called.
Andrew
^ permalink raw reply
* Re: [PATCH net] r8169: fix setting driver_data after register_netdev
From: Francois Romieu @ 2018-03-25 23:07 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, David Miller,
netdev@vger.kernel.org
In-Reply-To: <4fbb6b47-d4aa-2b21-34ba-383e085ed236@gmail.com>
Heiner Kallweit <hkallweit1@gmail.com> :
> pci_set_drvdata() is called only after registering the net_device,
> therefore we could run into a NPE if one of the functions using
> driver_data is called before it's set.
>
> Fix this by calling pci_set_drvdata() before registering the
> net_device.
>
> This fix is a candidate for stable. As far as I can see the
> bug has been there in kernel version 3.2 already, therefore
> I can't provide a reference which commit is fixed by it.
It does not sound convincing.
Please tell which functions are supposed to crash.
Suspend / resume ones ? Anything else ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Andrew Lunn @ 2018-03-25 23:06 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180325221004.6svjbx54yghwuk7w@localhost>
> > in the future some devices will be MDIO, or I2C, or SPI. Just call it
> > ptpdev. This ptpdev needs to be control bus agnostic. You need a
> > ptpdev core API exposing functions like ptpdev_hwtstamp,
> > ptpdev_rxtstamp, ptpdev_txtstamp, ptpdev_link_change, which take a
> > ptpdev.
>
> Well, this name is not ideal, since time stamping devices in general
> can time stamp any frame, not just PTP frames.
Hi Richard
I don't really care about the name. I care about the semantics of the
API. How about ieee1588_rxtstamp, ieee1588_txtstamp, etc.
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Andrew Lunn @ 2018-03-25 23:01 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180325221004.6svjbx54yghwuk7w@localhost>
> > You can then clean up the code in timestamping.c. Code like:
> >
> > phydev = skb->dev->phydev;
> > if (likely(phydev->drv->txtstamp)) {
> > clone = skb_clone_sk(skb);
> > if (!clone)
> > return;
> > phydev->drv->txtstamp(phydev, clone, type);
> > }
> >
> > violates the layering, and the locking looks broken.
>
> Are you sure the locking is broken? If so, how?
As a general rule of thumb, locking is performed in the core when
possible. Experience has shown that device driver writers get locking
wrong more often than core code writers. So doing it once in the core
results in less bugs.
The phylib core code will take the phydev lock before calling into the
driver. By violating the layering, we are missing on this lock.
Maybe the one driver which currently implements these calls does not
need locking. But after the Marvell DSA work, we have most of the code
needed to implement support for the Marvell PHY PTP. It has pretty
similar registers. That would need the phydev lock to be held, because
we need to swap to different pages, so any other calls happening in
parallel are going to see registers from the wrong page. I don't want
to have to put these locks in the driver, that leads to bugs. The core
should do it.
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Florian Fainelli @ 2018-03-25 23:01 UTC (permalink / raw)
To: Richard Cochran, Andrew Lunn
Cc: netdev, devicetree, David Miller, Mark Rutland, Miroslav Lichvar,
Rob Herring, Willem de Bruijn
In-Reply-To: <20180325221004.6svjbx54yghwuk7w@localhost>
On 03/25/2018 03:10 PM, Richard Cochran wrote:
> On Sun, Mar 25, 2018 at 05:59:37PM +0200, Andrew Lunn wrote:
>>>> 3) How do you limit the MAC/PHY to what the PTP device can do.
>>>
>>> Hm, I don't think this is important.
>>
>> So you are happy that the PTP device will cause the MC/PHY link to
>> break down when it is asked to do something it cannot do?
>
> No, but I do expect the system designer to use common sense. No need
> to over engineer this now just to catch hypothetical future problems.
>
>>> Right, so phylib can operate on phydev->attached_dev->mdiots;
>>
>> So first off, it is not an MDIO device.
>
> ...
>
>> To keep lifecycle issues simple, i would also keep it in phydev, not
>> netdev.
>>
>> mdiots as a name is completely wrong. It is not an MDIO device.
>
> I am well aware of what terms MDIO and MII represent, but our current
> code is hopelessly confused. Case in point:
>
> static inline struct mii_bus *mdiobus_alloc(void);
>
> The kernel's 'struct mii_bus' is really only about MDIO and not about
> the rest of MII. Clearly MII time stamping devices belong on the MII
> bus, so that is where I put them.
They do, if and only if their control path goes through the MDIO bus,
this one does not, see below.
>
> Or maybe mii_bus should first be renamed to mdio_bus? That you pave
> the way for introducing a representation of the MII bus.
It would have been ideal to name this structure mdio_bus, because that
is what it indeed is. An argument could be made this is true about a lot
of devices though, e.g: PCIe end point drivers do register a
pci_driver/device, not a pcie_driver/device...
Andrew still has a valid point though that devices are child of their
control bus, not data bus. The data bus here is MII, but the control bus
is here through MMIO register, therefore platform device in Linux's
device driver model so we would expect the
The best that I can think about and it still is a hack in some way, is
to you have your time stamping driver create a proxy mii_bus whose
purpose is just to hook to mdio/phy_device events (such as link changes)
in order to do what is necessary, or at least, this would indicate its
transparent nature towards the MDIO/MDC lines...
What is not great in your current binding is that you created a notion
of "port" which is tied to the timestamper device, whereas it really
seems to be a property of the Ethernet controller, where the datapath
being timestamped resides.
Tangential: the existing PHY time stamping logic should probably be
generalized to a mdio_device (which the phy_device is a specialized
superset of) instead of to the phy_device. This would still allow
existing use cases but it would also allow us to support possible "pure
MDIO" devices would that become some thing in the future.
>
>> in the future some devices will be MDIO, or I2C, or SPI. Just call it
>> ptpdev. This ptpdev needs to be control bus agnostic. You need a
>> ptpdev core API exposing functions like ptpdev_hwtstamp,
>> ptpdev_rxtstamp, ptpdev_txtstamp, ptpdev_link_change, which take a
>> ptpdev.
>
> Well, this name is not ideal, since time stamping devices in general
> can time stamp any frame, not just PTP frames.
>
>> You can then clean up the code in timestamping.c. Code like:
>>
>> phydev = skb->dev->phydev;
>> if (likely(phydev->drv->txtstamp)) {
>> clone = skb_clone_sk(skb);
>> if (!clone)
>> return;
>> phydev->drv->txtstamp(phydev, clone, type);
>> }
>>
>> violates the layering, and the locking looks broken.
>
> Are you sure the locking is broken? If so, how?
>
> (This code path has been reviewed more than once.)
>
> Can you please explain the layering and how this code breaks it?
I see it both ways, you either invoke an operation to timestamp which
goes into an abstract "timestamping device" which invokes a driver to
determine the actual operation, or you can do what you did which was to
augment struct net_device with a phy_device, under the premise this will
be the only type of timestamping capable device we will ever see.
This is no longer holding true, your patches are a testament to that, so
now you need another member: mdiots, as you can see, there is now
overlap between the two, because a phy_device should arguably be
encapsulating a mdiots device object...
>
> (This code goes back to 2.6.36 and perhaps predates the layers that
> were added later on.)
>
> Thanks,
> Richard
>
--
Florian
^ permalink raw reply
* [PATCH net] r8169: fix setting driver_data after register_netdev
From: Heiner Kallweit @ 2018-03-25 22:32 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
pci_set_drvdata() is called only after registering the net_device,
therefore we could run into a NPE if one of the functions using
driver_data is called before it's set.
Fix this by calling pci_set_drvdata() before registering the
net_device.
This fix is a candidate for stable. As far as I can see the
bug has been there in kernel version 3.2 already, therefore
I can't provide a reference which commit is fixed by it.
The fix may need small adjustments per kernel version because
due to other changes the label which is jumped to if
register_netdev() fails has changed over time.
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 630409e0..604ae783 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8378,12 +8378,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!tp->counters)
return -ENOMEM;
+ pci_set_drvdata(pdev, dev);
+
rc = register_netdev(dev);
if (rc < 0)
return rc;
- pci_set_drvdata(pdev, dev);
-
netif_info(tp, probe, dev, "%s at 0x%p, %pM, XID %08x IRQ %d\n",
rtl_chip_infos[chipset].name, tp->mmio_addr, dev->dev_addr,
(u32)(RTL_R32(tp, TxConfig) & 0x9cf0f8ff),
--
2.16.2
^ permalink raw reply related
* linux-next: manual merge of the ipsec tree with the net tree
From: Stephen Rothwell @ 2018-03-25 22:16 UTC (permalink / raw)
To: Steffen Klassert, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Petr Machata,
Stefano Brivio
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
Hi Steffen,
Today's linux-next merge of the ipsec tree got a conflict in:
net/ipv4/ip_tunnel.c
between commit:
f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
from the net tree and commit:
24fc79798b8d ("ip_tunnel: Clamp MTU to bounds on new link")
from the ipsec tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ip_tunnel.c
index 7b85ffad5d74,7c76dd17b6b9..000000000000
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@@ -1117,10 -1108,13 +1117,15 @@@ int ip_tunnel_newlink(struct net_devic
eth_hw_addr_random(dev);
mtu = ip_tunnel_bind_dev(dev);
- if (!tb[IFLA_MTU]) {
+ if (tb[IFLA_MTU]) {
+ unsigned int max = 0xfff8 - dev->hard_header_len - nt->hlen;
+
+ dev->mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
+ (unsigned int)(max - sizeof(struct iphdr)));
+ } else {
- dev->mtu = mtu;
+ err = dev_set_mtu(dev, mtu);
+ if (err)
+ goto err_dev_set_mtu;
}
ip_tunnel_add(itn, nt);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Richard Cochran @ 2018-03-25 22:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180325155937.GA12820@lunn.ch>
On Sun, Mar 25, 2018 at 05:59:37PM +0200, Andrew Lunn wrote:
> To keep lifecycle issues simple, i would also keep it in phydev, not
> netdev.
Okay.
Since we don't have any representation for MII anyhow, it seems equally
fitting to attach this to the PHY's data structure as to the MAC's.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Richard Cochran @ 2018-03-25 22:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180325155937.GA12820@lunn.ch>
On Sun, Mar 25, 2018 at 05:59:37PM +0200, Andrew Lunn wrote:
> > > 3) How do you limit the MAC/PHY to what the PTP device can do.
> >
> > Hm, I don't think this is important.
>
> So you are happy that the PTP device will cause the MC/PHY link to
> break down when it is asked to do something it cannot do?
No, but I do expect the system designer to use common sense. No need
to over engineer this now just to catch hypothetical future problems.
> > Right, so phylib can operate on phydev->attached_dev->mdiots;
>
> So first off, it is not an MDIO device.
...
> To keep lifecycle issues simple, i would also keep it in phydev, not
> netdev.
>
> mdiots as a name is completely wrong. It is not an MDIO device.
I am well aware of what terms MDIO and MII represent, but our current
code is hopelessly confused. Case in point:
static inline struct mii_bus *mdiobus_alloc(void);
The kernel's 'struct mii_bus' is really only about MDIO and not about
the rest of MII. Clearly MII time stamping devices belong on the MII
bus, so that is where I put them.
Or maybe mii_bus should first be renamed to mdio_bus? That you pave
the way for introducing a representation of the MII bus.
> in the future some devices will be MDIO, or I2C, or SPI. Just call it
> ptpdev. This ptpdev needs to be control bus agnostic. You need a
> ptpdev core API exposing functions like ptpdev_hwtstamp,
> ptpdev_rxtstamp, ptpdev_txtstamp, ptpdev_link_change, which take a
> ptpdev.
Well, this name is not ideal, since time stamping devices in general
can time stamp any frame, not just PTP frames.
> You can then clean up the code in timestamping.c. Code like:
>
> phydev = skb->dev->phydev;
> if (likely(phydev->drv->txtstamp)) {
> clone = skb_clone_sk(skb);
> if (!clone)
> return;
> phydev->drv->txtstamp(phydev, clone, type);
> }
>
> violates the layering, and the locking looks broken.
Are you sure the locking is broken? If so, how?
(This code path has been reviewed more than once.)
Can you please explain the layering and how this code breaks it?
(This code goes back to 2.6.36 and perhaps predates the layers that
were added later on.)
Thanks,
Richard
^ 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