* KASAN: out-of-bounds Read in rds_cong_queue_updates (2)
From: syzbot @ 2018-06-13 7:51 UTC (permalink / raw)
To: davem, linux-kernel, linux-rdma, netdev, rds-devel,
santosh.shilimkar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0adb32858b0b Linux 4.16
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=138f2d0b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=df0c336cc3b55d45
dashboard link: https://syzkaller.appspot.com/bug?extid=287843ad8a4d2870e538
compiler: gcc (GCC) 7.1.1 20170620
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+287843ad8a4d2870e538@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: out-of-bounds in __read_once_size include/linux/compiler.h:188
[inline]
BUG: KASAN: out-of-bounds in atomic_read arch/x86/include/asm/atomic.h:27
[inline]
BUG: KASAN: out-of-bounds in refcount_read include/linux/refcount.h:42
[inline]
BUG: KASAN: out-of-bounds in check_net include/net/net_namespace.h:228
[inline]
BUG: KASAN: out-of-bounds in rds_destroy_pending net/rds/rds.h:868 [inline]
BUG: KASAN: out-of-bounds in rds_cong_queue_updates+0x4d3/0x4f0
net/rds/cong.c:226
Read of size 4 at addr ffff88018d7f2204 by task kworker/u4:6/10561
CPU: 1 PID: 10561 Comm: kworker/u4:6 Not tainted 4.16.0+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
kernel msg: ebtables bug: please report to author: Wrong len argument
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23c/0x360 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
__read_once_size include/linux/compiler.h:188 [inline]
atomic_read arch/x86/include/asm/atomic.h:27 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:228 [inline]
rds_destroy_pending net/rds/rds.h:868 [inline]
rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
The buggy address belongs to the page:
page:ffffea000635fc80 count:3 mapcount:2 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 0000000300000001
raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88018d7f2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88018d7f2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88018d7f2200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ffff88018d7f2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88018d7f2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 10561 Comm: kworker/u4:6 Tainted: G B 4.16.0+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
kasan_end_report+0x50/0x50 mm/kasan/report.c:180
kasan_report_error mm/kasan/report.c:359 [inline]
kasan_report+0x149/0x360 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
__read_once_size include/linux/compiler.h:188 [inline]
atomic_read arch/x86/include/asm/atomic.h:27 [inline]
refcount_read include/linux/refcount.h:42 [inline]
check_net include/net/net_namespace.h:228 [inline]
rds_destroy_pending net/rds/rds.h:868 [inline]
rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
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.
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates
From: Dmitry Vyukov @ 2018-06-13 7:51 UTC (permalink / raw)
To: syzbot, Sowmini Varadhan
Cc: David Miller, LKML, linux-rdma, netdev, rds-devel,
Santosh Shilimkar, syzkaller-bugs
In-Reply-To: <000000000000a643e4056e7d0db4@google.com>
On Wed, Jun 13, 2018 at 4:51 AM, syzbot
<syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com> wrote:
> syzbot has found a reproducer for the following crash on:
Woohoo! Please take a look, this is a top crasher.
> HEAD commit: f0dc7f9c6dd9 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1461f03f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=fa9c20c48788d1c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=4c20b3866171ce8441d2
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16cbfeaf800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=165227f7800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com
>
> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
> 8021q: adding VLAN 0 to HW filter on device team0
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> ==================================================================
> BUG: KASAN: use-after-free in atomic_read
> include/asm-generic/atomic-instrumented.h:21 [inline]
> BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:42
> [inline]
> BUG: KASAN: use-after-free in check_net include/net/net_namespace.h:236
> [inline]
> BUG: KASAN: use-after-free in rds_destroy_pending net/rds/rds.h:897 [inline]
> BUG: KASAN: use-after-free in rds_cong_queue_updates+0x255/0x590
> net/rds/cong.c:226
> Read of size 4 at addr ffff8801ab180044 by task syz-executor199/4800
>
> CPU: 1 PID: 4800 Comm: syz-executor199 Not tainted 4.17.0+ #84
> 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
> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
> kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
> atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
> refcount_read include/linux/refcount.h:42 [inline]
> check_net include/net/net_namespace.h:236 [inline]
> rds_destroy_pending net/rds/rds.h:897 [inline]
> rds_cong_queue_updates+0x255/0x590 net/rds/cong.c:226
> rds_recv_rcvbuf_delta.part.3+0x211/0x350 net/rds/recv.c:126
> rds_recv_rcvbuf_delta net/rds/recv.c:735 [inline]
> rds_clear_recv_queue+0x2f0/0x4c0 net/rds/recv.c:735
> rds_release+0x15c/0x550 net/rds/af_rds.c:72
> __sock_release+0xd7/0x260 net/socket.c:603
> sock_close+0x19/0x20 net/socket.c:1186
> __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:2468
> do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2cf/0x360 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x44f439
> Code: e8 ac be 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 5b ff fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fc65567dcf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: fffffffffffffe00 RBX: 00000000006edadc RCX: 000000000044f439
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006edadc
> RBP: 00000000006edad8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff3df31b1f R14: 00007fc65567e9c0 R15: 0000000000000061
>
> Allocated by task 4800:
> 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
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
> kmem_cache_zalloc include/linux/slab.h:696 [inline]
> net_alloc net/core/net_namespace.c:383 [inline]
> copy_net_ns+0x159/0x4c0 net/core/net_namespace.c:423
> create_new_namespaces+0x69d/0x8f0 kernel/nsproxy.c:107
> unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:206
> ksys_unshare+0x708/0xf90 kernel/fork.c:2411
> __do_sys_unshare kernel/fork.c:2479 [inline]
> __se_sys_unshare kernel/fork.c:2477 [inline]
> __x64_sys_unshare+0x31/0x40 kernel/fork.c:2477
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 746:
> 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]
> kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
> net_free net/core/net_namespace.c:399 [inline]
> net_drop_ns.part.14+0x11a/0x130 net/core/net_namespace.c:406
> net_drop_ns net/core/net_namespace.c:405 [inline]
> cleanup_net+0x6a1/0xb20 net/core/net_namespace.c:541
> process_one_work+0xc64/0x1b70 kernel/workqueue.c:2153
> worker_thread+0x181/0x13a0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> The buggy address belongs to the object at ffff8801ab180040
> which belongs to the cache net_namespace(17:syz0) of size 8896
> The buggy address is located 4 bytes inside of
> 8896-byte region [ffff8801ab180040, ffff8801ab182300)
> The buggy address belongs to the page:
> page:ffffea0006ac6000 count:1 mapcount:0 mapping:ffff8801aeaa0080 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffff8801d3827048 ffff8801d3827048 ffff8801aeaa0080
> raw: 0000000000000000 ffff8801ab180040 0000000100000001 ffff8801ab7cae40
> page dumped because: kasan: bad access detected
> page->mem_cgroup:ffff8801ab7cae40
>
> Memory state around the buggy address:
> ffff8801ab17ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801ab17ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ^
> ffff8801ab180080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801ab180100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000a643e4056e7d0db4%40google.com.
>
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: KASAN: out-of-bounds Read in rds_cong_queue_updates (2)
From: Dmitry Vyukov @ 2018-06-13 7:52 UTC (permalink / raw)
To: syzbot, Sowmini Varadhan
Cc: David Miller, LKML, linux-rdma, netdev, rds-devel,
Santosh Shilimkar, syzkaller-bugs
In-Reply-To: <00000000000081bd9d056e813e48@google.com>
On Wed, Jun 13, 2018 at 9:51 AM, syzbot
<syzbot+287843ad8a4d2870e538@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0adb32858b0b Linux 4.16
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=138f2d0b800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df0c336cc3b55d45
> dashboard link: https://syzkaller.appspot.com/bug?extid=287843ad8a4d2870e538
> compiler: gcc (GCC) 7.1.1 20170620
>
> 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+287843ad8a4d2870e538@syzkaller.appspotmail.com
I think this is:
#syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
> ==================================================================
> BUG: KASAN: out-of-bounds in __read_once_size include/linux/compiler.h:188
> [inline]
> BUG: KASAN: out-of-bounds in atomic_read arch/x86/include/asm/atomic.h:27
> [inline]
> BUG: KASAN: out-of-bounds in refcount_read include/linux/refcount.h:42
> [inline]
> BUG: KASAN: out-of-bounds in check_net include/net/net_namespace.h:228
> [inline]
> BUG: KASAN: out-of-bounds in rds_destroy_pending net/rds/rds.h:868 [inline]
> BUG: KASAN: out-of-bounds in rds_cong_queue_updates+0x4d3/0x4f0
> net/rds/cong.c:226
> Read of size 4 at addr ffff88018d7f2204 by task kworker/u4:6/10561
>
> CPU: 1 PID: 10561 Comm: kworker/u4:6 Not tainted 4.16.0+ #10
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: krdsd rds_send_worker
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> kernel msg: ebtables bug: please report to author: Wrong len argument
> print_address_description+0x73/0x250 mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report+0x23c/0x360 mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> __read_once_size include/linux/compiler.h:188 [inline]
> atomic_read arch/x86/include/asm/atomic.h:27 [inline]
> refcount_read include/linux/refcount.h:42 [inline]
> check_net include/net/net_namespace.h:228 [inline]
> rds_destroy_pending net/rds/rds.h:868 [inline]
> rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
> rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
> rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
> rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
> rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
> rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
> rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
> process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
> worker_thread+0x223/0x1990 kernel/workqueue.c:2247
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
>
> The buggy address belongs to the page:
> page:ffffea000635fc80 count:3 mapcount:2 mapping:0000000000000000 index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 0000000000000000 0000000000000000 0000000300000001
> raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88018d7f2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88018d7f2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
> ffff88018d7f2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88018d7f2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 10561 Comm: kworker/u4:6 Tainted: G B 4.16.0+ #10
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: krdsd rds_send_worker
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> kasan_end_report+0x50/0x50 mm/kasan/report.c:180
> kasan_report_error mm/kasan/report.c:359 [inline]
> kasan_report+0x149/0x360 mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> __read_once_size include/linux/compiler.h:188 [inline]
> atomic_read arch/x86/include/asm/atomic.h:27 [inline]
> refcount_read include/linux/refcount.h:42 [inline]
> check_net include/net/net_namespace.h:228 [inline]
> rds_destroy_pending net/rds/rds.h:868 [inline]
> rds_cong_queue_updates+0x4d3/0x4f0 net/rds/cong.c:226
> rds_recv_rcvbuf_delta.part.2+0x289/0x320 net/rds/recv.c:118
> rds_recv_rcvbuf_delta net/rds/recv.c:377 [inline]
> rds_recv_incoming+0xeb4/0x11d0 net/rds/recv.c:377
> rds_loop_xmit+0x149/0x320 net/rds/loop.c:82
> rds_send_xmit+0xbcd/0x26b0 net/rds/send.c:355
> rds_send_worker+0x115/0x2a0 net/rds/threads.c:199
> process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
> worker_thread+0x223/0x1990 kernel/workqueue.c:2247
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/00000000000081bd9d056e813e48%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates
From: santosh.shilimkar @ 2018-06-13 7:54 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot
Cc: Sowmini Varadhan, David Miller, LKML, linux-rdma, netdev,
rds-devel, syzkaller-bugs
In-Reply-To: <CACT4Y+b+DFpa34E3UWzSYn6qy-BMmxN80ikdmU_xMe9x9JF2+Q@mail.gmail.com>
On 6/13/18 12:51 AM, Dmitry Vyukov wrote:
> On Wed, Jun 13, 2018 at 4:51 AM, syzbot
> <syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com> wrote:
>> syzbot has found a reproducer for the following crash on:
>
> Woohoo! Please take a look, this is a top crasher.
>
Will have a look Dmitry !!
^ permalink raw reply
* [PATCH bpf] xdp: Fix handling of devmap in generic XDP
From: Toshiaki Makita @ 2018-06-13 8:06 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Toshiaki Makita, netdev, Jesper Dangaard Brouer
Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
the return value type of __devmap_lookup_elem() from struct net_device *
to struct bpf_dtab_netdev * but forgot to modify generic XDP code
accordingly.
Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
net_device is expected, then skb->dev was set to invalid value.
Fixes: 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
include/linux/bpf.h | 10 ++++++++++
include/linux/filter.h | 16 ++++++++++++++++
kernel/bpf/devmap.c | 14 ++++++++++++++
net/core/filter.c | 21 ++++-----------------
4 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 995c3b1..2fe3aa1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -487,6 +487,7 @@ static inline void bpf_long_memcpy(void *dst, const void *src, u32 size)
void bpf_patch_call_args(struct bpf_insn *insn, u32 stack_depth);
/* Map specifics */
+struct sk_buff;
struct xdp_buff;
struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key);
@@ -494,6 +495,8 @@ static inline void bpf_long_memcpy(void *dst, const void *src, u32 size)
void __dev_map_flush(struct bpf_map *map);
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
struct net_device *dev_rx);
+int dev_map_generic_redirect(struct bpf_dtab_netdev *dst, struct sk_buff *skb,
+ struct bpf_prog *xdp_prog);
struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key);
void __cpu_map_insert_ctx(struct bpf_map *map, u32 index);
@@ -586,6 +589,13 @@ int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
return 0;
}
+static inline int dev_map_generic_redirect(struct bpf_dtab_netdev *dst,
+ struct sk_buff *skb,
+ struct bpf_prog *xdp_prog)
+{
+ return 0;
+}
+
static inline
struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key)
{
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 45fc0f5..8ddff1f 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -19,6 +19,7 @@
#include <linux/cryptohash.h>
#include <linux/set_memory.h>
#include <linux/kallsyms.h>
+#include <linux/if_vlan.h>
#include <net/sch_generic.h>
@@ -786,6 +787,21 @@ static inline bool bpf_dump_raw_ok(void)
struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off,
const struct bpf_insn *patch, u32 len);
+static inline int __xdp_generic_ok_fwd_dev(struct sk_buff *skb,
+ struct net_device *fwd)
+{
+ unsigned int len;
+
+ if (unlikely(!(fwd->flags & IFF_UP)))
+ return -ENETDOWN;
+
+ len = fwd->mtu + fwd->hard_header_len + VLAN_HLEN;
+ if (skb->len > len)
+ return -EMSGSIZE;
+
+ return 0;
+}
+
/* The pair of xdp_do_redirect and xdp_do_flush_map MUST be called in the
* same cpu context. Further for best results no more than a single map
* for the do_redirect/do_flush pair should be used. This limitation is
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index a7cc7b3..642c97f 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -345,6 +345,20 @@ int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
return bq_enqueue(dst, xdpf, dev_rx);
}
+int dev_map_generic_redirect(struct bpf_dtab_netdev *dst, struct sk_buff *skb,
+ struct bpf_prog *xdp_prog)
+{
+ int err;
+
+ err = __xdp_generic_ok_fwd_dev(skb, dst->dev);
+ if (unlikely(err))
+ return err;
+ skb->dev = dst->dev;
+ generic_xdp_tx(skb, xdp_prog);
+
+ return 0;
+}
+
static void *dev_map_lookup_elem(struct bpf_map *map, void *key)
{
struct bpf_dtab_netdev *obj = __dev_map_lookup_elem(map, *(u32 *)key);
diff --git a/net/core/filter.c b/net/core/filter.c
index 3d9ba7e..e7f12e9 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3214,20 +3214,6 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
-static int __xdp_generic_ok_fwd_dev(struct sk_buff *skb, struct net_device *fwd)
-{
- unsigned int len;
-
- if (unlikely(!(fwd->flags & IFF_UP)))
- return -ENETDOWN;
-
- len = fwd->mtu + fwd->hard_header_len + VLAN_HLEN;
- if (skb->len > len)
- return -EMSGSIZE;
-
- return 0;
-}
-
static int xdp_do_generic_redirect_map(struct net_device *dev,
struct sk_buff *skb,
struct xdp_buff *xdp,
@@ -3256,10 +3242,11 @@ static int xdp_do_generic_redirect_map(struct net_device *dev,
}
if (map->map_type == BPF_MAP_TYPE_DEVMAP) {
- if (unlikely((err = __xdp_generic_ok_fwd_dev(skb, fwd))))
+ struct bpf_dtab_netdev *dst = fwd;
+
+ err = dev_map_generic_redirect(dst, skb, xdp_prog);
+ if (unlikely(err))
goto err;
- skb->dev = fwd;
- generic_xdp_tx(skb, xdp_prog);
} else if (map->map_type == BPF_MAP_TYPE_XSKMAP) {
struct xdp_sock *xs = fwd;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-queue] i40e: Fix incorrect skb reserved size on rx
From: Toshiaki Makita @ 2018-06-13 8:08 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Toshiaki Makita, Daniel Borkmann, John Fastabend, intel-wired-lan,
netdev
i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary here
and mac_header/data feilds in skb becomes incorrect, and breaks normal
skb receive path as well as XDP receive path.
Fixes: cc5b114dcf98 ("bpf, i40e: add meta data support")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 8ffb7454e67c..6d59f51f1730 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2124,7 +2124,7 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
return NULL;
/* update pointers within the skb to store the data */
- skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start));
+ skb_reserve(skb, xdp->data - xdp->data_hard_start);
__skb_put(skb, xdp->data_end - xdp->data);
if (metasize)
skb_metadata_set(skb, metasize);
--
2.14.2
^ permalink raw reply related
* Re: [RFC PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Roger Pau Monné @ 2018-06-13 8:24 UTC (permalink / raw)
To: Anchal Agarwal
Cc: tglx, mingo, hpa, x86, boris.ostrovsky, konrad.wilk, netdev,
jgross, xen-devel, linux-kernel, kamatam, fllinden, vallish,
guruanb, eduval, rjw, pavel, len.brown, linux-pm, cyberax
In-Reply-To: <20180612205619.28156-7-anchalag@amazon.com>
On Tue, Jun 12, 2018 at 08:56:13PM +0000, Anchal Agarwal wrote:
> From: Munehisa Kamata <kamatam@amazon.com>
>
> Add freeze and restore callbacks for PM suspend and hibernation support.
> The freeze handler stops a block-layer queue and disconnect the frontend
> from the backend while freeing ring_info and associated resources. The
> restore handler re-allocates ring_info and re-connect to the backedend,
> so the rest of the kernel can continue to use the block device
> transparently.Also, the handlers are used for both PM
> suspend and hibernation so that we can keep the existing suspend/resume
> callbacks for Xen suspend without modification.
> If a backend doesn't have commit 12ea729645ac ("xen/blkback: unmap all
> persistent grants when frontend gets disconnected"), the frontend may see
> massive amount of grant table warning when freeing resources.
>
> [ 36.852659] deferring g.e. 0xf9 (pfn 0xffffffffffffffff)
> [ 36.855089] xen:grant_table: WARNING: g.e. 0x112 still in use!
>
> In this case, persistent grants would need to be disabled.
>
> Ensure no reqs/rsps in rings before disconnecting. When disconnecting
> the frontend from the backend in blkfront_freeze(), there still may be
> unconsumed requests or responses in the rings, especially when the
> backend is backed by network-based device. If the frontend gets
> disconnected with such reqs/rsps remaining there, it can cause
> grant warnings and/or losing reqs/rsps by freeing pages afterward.
I'm not sure why having pending requests can cause grant warnings or
lose of requests. If handled properly this shouldn't be an issue.
Linux blkfront already does live migration (which also involves a
reconnection of the frontend) with pending requests and that doesn't
seem to be an issue.
> This can lead resumed kernel into unrecoverable state like unexpected
> freeing of grant page and/or hung task due to the lost reqs or rsps.
> Therefore we have to ensure that there is no unconsumed requests or
> responses before disconnecting.
Given that we have multiqueue, plus multipage rings, I'm not sure
waiting for the requests on the rings to complete is a good idea.
Why can't you just disconnect the frontend and requeue all the
requests in flight? When the frontend connects on resume those
requests will be queued again.
Thanks, Roger.
^ permalink raw reply
* Re: FW: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
From: Kalle Valo @ 2018-06-13 8:47 UTC (permalink / raw)
To: Niklas Cassel
Cc: Govind Singh, bjorn.andersson, davem, netdev, linux-wireless,
linux-kernel, ath10k
In-Reply-To: <20180612124403.GA26986@centauri.lan>
Niklas Cassel <niklas.cassel@linaro.org> writes:
> On Tue, Jun 12, 2018 at 06:02:48PM +0530, Govind Singh wrote:
>> On 2018-06-12 17:45, Govind Singh wrote:
>> > -----Original Message-----
>> > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Niklas
>> > Cassel
>> > Sent: Tuesday, June 12, 2018 5:09 PM
>> > To: Kalle Valo <kvalo@codeaurora.org>; David S. Miller
>> > <davem@davemloft.net>
>> > Cc: Niklas Cassel <niklas.cassel@linaro.org>; netdev@vger.kernel.org;
>> > linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org;
>> > ath10k@lists.infradead.org
>> > Subject: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
>> >
>> > ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
>> >
>> > Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
>> > ---
>> > drivers/net/wireless/ath/ath10k/Kconfig | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
>> > b/drivers/net/wireless/ath/ath10k/Kconfig
>> > index 54ff5930126c..6572a43590a8 100644
>> > --- a/drivers/net/wireless/ath/ath10k/Kconfig
>> > +++ b/drivers/net/wireless/ath/ath10k/Kconfig
>> > @@ -42,7 +42,8 @@ config ATH10K_USB
>> >
>> > config ATH10K_SNOC
>> > tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
>> > - depends on ATH10K && ARCH_QCOM
>> > + depends on ATH10K
>> > + depends on ARCH_QCOM || COMPILE_TEST
>> > ---help---
>> > This module adds support for integrated WCN3990 chip connected
>> > to system NOC(SNOC). Currently work in progress and will not
>>
>> Thanks Niklas for enabling COMPILE_TEST. With QMI set of
>> changes(https://patchwork.kernel.org/patch/10448183/), we need to enable
>> COMPILE_TEST for
>> QCOM_SCM/QMI_HELPERS which seems broken today. Are you planning to fix the
>> same.
>
>
> Argh..
>
> qcom_scm seems fine, it is just missing a single definition in the
> #else clause of include/linux/qcom_scm.h.
>
> +++ b/include/linux/qcom_scm.h
> @@ -89,6 +89,10 @@ static inline int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr,
> static inline int
> qcom_scm_pas_auth_and_reset(u32 peripheral) { return -ENODEV; }
> static inline int qcom_scm_pas_shutdown(u32 peripheral) { return -ENODEV; }
> +static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
> + unsigned int *src,
> + struct qcom_scm_vmperm *newvm,
> + int dest_cnt) { return -ENODEV; }
> static inline void qcom_scm_cpu_power_down(u32 flags) {}
> static inline u32 qcom_scm_get_version(void) { return 0; }
>
>
>
> include/linux/soc/qcom/qmi.h on the other hand doesn't have any
> dummy defintions at all.
> I think that it makes sense to be able to compile test
> the QMI helpers also on other archs..
>
> Bjorn, any opinion?
Please don't drop ath10k list, adding it back.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH bpf] xdp: Fix handling of devmap in generic XDP
From: kbuild test robot @ 2018-06-13 8:51 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
netdev, Jesper Dangaard Brouer
In-Reply-To: <1528877178-2521-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
Hi Toshiaki,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf/master]
url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/xdp-Fix-handling-of-devmap-in-generic-XDP/20180613-161204
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git master
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=parisc
All warnings (new ones prefixed by >>):
In file included from net/bpf/test_run.c:7:0:
>> include/linux/bpf.h:593:16: warning: 'struct sk_buff' declared inside parameter list will not be visible outside of this definition or declaration
struct sk_buff *skb,
^~~~~~~
vim +593 include/linux/bpf.h
591
592 static inline int dev_map_generic_redirect(struct bpf_dtab_netdev *dst,
> 593 struct sk_buff *skb,
594 struct bpf_prog *xdp_prog)
595 {
596 return 0;
597 }
598
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 14461 bytes --]
^ permalink raw reply
* [PATCH net/jkirsher] bpf, xdp, i40e: fix i40e_build_skb skb reserve and truesize
From: Daniel Borkmann @ 2018-06-13 9:04 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: intel-wired-lan, keith.busch, makita.toshiaki, bjorn.topel,
john.fastabend, netdev, Daniel Borkmann
Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
is clearly wrong since I40E_SKB_PAD already points to the offset where
the original xdp->data was sitting since xdp->data_hard_start is defined
as xdp->data - i40e_rx_offset(rx_ring) where latter offsets to I40E_SKB_PAD
when build skb is used.
However, also before cc5b114dcf98 ("bpf, i40e: add meta data support")
this seems broken since bpf_xdp_adjust_head() helper could have been used
to alter headroom and enlarge / shrink the frame and with that the assumption
that the xdp->data remains unchanged does not hold and would push a bogus
packet to upper stack.
ixgbe got this right in 924708081629 ("ixgbe: add XDP support for pass and
drop actions"). In any case, fix it by removing the I40E_SKB_PAD from both
skb_reserve() and truesize calculation.
Fixes: cc5b114dcf98 ("bpf, i40e: add meta data support")
Fixes: 0c8493d90b6b ("i40e: add XDP support for pass and drop actions")
Reported-by: Keith Busch <keith.busch@linux.intel.com>
Reported-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Björn Töpel <bjorn.topel@intel.com>
Cc: John Fastabend <john.fastabend@gmail.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 8ffb745..ed6dbcf 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2103,9 +2103,8 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
unsigned int truesize = i40e_rx_pg_size(rx_ring) / 2;
#else
unsigned int truesize = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
- SKB_DATA_ALIGN(I40E_SKB_PAD +
- (xdp->data_end -
- xdp->data_hard_start));
+ SKB_DATA_ALIGN(xdp->data_end -
+ xdp->data_hard_start);
#endif
struct sk_buff *skb;
@@ -2124,7 +2123,7 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
return NULL;
/* update pointers within the skb to store the data */
- skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start));
+ skb_reserve(skb, xdp->data - xdp->data_hard_start);
__skb_put(skb, xdp->data_end - xdp->data);
if (metasize)
skb_metadata_set(skb, metasize);
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-queue] i40e: Fix incorrect skb reserved size on rx
From: Daniel Borkmann @ 2018-06-13 9:06 UTC (permalink / raw)
To: Toshiaki Makita, Jeff Kirsher; +Cc: John Fastabend, intel-wired-lan, netdev
In-Reply-To: <1528877310-2574-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 06/13/2018 10:08 AM, Toshiaki Makita wrote:
> i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
> xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary here
> and mac_header/data feilds in skb becomes incorrect, and breaks normal
> skb receive path as well as XDP receive path.
>
> Fixes: cc5b114dcf98 ("bpf, i40e: add meta data support")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Thanks Toshiaki, I sent a complete fix yesterday here:
https://lkml.org/lkml/2018/6/12/843
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-13 9:15 UTC (permalink / raw)
To: David Miller
Cc: dnelson, rric, sgoutham, linux-arm-kernel, netdev, linux-kernel,
Vadim.Lomovtsev
In-Reply-To: <20180612.152540.1304714747425091865.davem@davemloft.net>
Sorry for delay.
On Tue, Jun 12, 2018 at 03:25:40PM -0700, David Miller wrote:
> From: Dean Nelson <dnelson@redhat.com>
> Date: Mon, 11 Jun 2018 06:22:14 -0500
>
> > On 06/10/2018 02:35 PM, David Miller wrote:
> >> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> >> Date: Fri, 8 Jun 2018 02:27:59 -0700
> >>
> >>> + /* Save message data locally to prevent them from
> >>> + * being overwritten by next ndo_set_rx_mode call().
> >>> + */
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + mode = vf_work->mode;
> >>> + mc = vf_work->mc;
> >>> + vf_work->mc = NULL;
> >
> > If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> > will
> > have been set to NULL before the lock is dropped by
> > nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
> >
> >
> >>> + spin_unlock(&nic->rx_mode_wq_lock);
> >> At the moment you drop this lock, the memory behind 'mc' can be
> >> freed up by:
> >>
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + kfree(nic->rx_mode_work.mc);
> >
> > So the kfree() will be called with a NULL pointer and quickly return.
> >
> >
> >> And you'll crash when you dereference it above via
> >> __nicvf_set_rx_mode_task().
> >>
> >
> > I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> > up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> > previous callback to the function, one that has not yet been processed
> > by nicvf_set_rx_mode_task().
> >
> > In this way only the last 'unprocessed' callback to
> > nicvf_set_rx_mode()
> > gets processed should there be multiple callbacks occurring between
> > the
> > times the nicvf_set_rx_mode_task() runs.
> >
> > In my testing with this patch, this is what I see happening.
>
> You're right, my bad.
>
> Patch applied.
Thank you for your time.
WBR,
Vadim
^ permalink raw reply
* Re: [PATCH 2/2] WAN: LMC: ensure lmc_trace is reporting return from lmc_proto_type
From: Dan Carpenter @ 2018-06-13 9:22 UTC (permalink / raw)
To: Colin King; +Cc: David S . Miller, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180613060410.735-2-colin.king@canonical.com>
On Wed, Jun 13, 2018 at 07:04:10AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently the lmc tracing is not reporting the return from function
> lmc_proto_type and this tracing statement is never executed. Fix
> this by returning through the end of the function. Also fix a typo
> in the function name lmc_proto_type in the trace message.
>
> Detected by CoverityScan, CID#710539 ("Structurally dead code")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wan/lmc/lmc_proto.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wan/lmc/lmc_proto.c b/drivers/net/wan/lmc/lmc_proto.c
> index 5a6c87bce1bf..b98c1ee860de 100644
> --- a/drivers/net/wan/lmc/lmc_proto.c
> +++ b/drivers/net/wan/lmc/lmc_proto.c
> @@ -99,23 +99,27 @@ void lmc_proto_close(lmc_softc_t *sc)
>
> __be16 lmc_proto_type(lmc_softc_t *sc, struct sk_buff *skb) /*FOLD00*/
> {
> + __be16 ret;
> +
> lmc_trace(sc->lmc_device, "lmc_proto_type in");
Did you take a look at lmc_trace()? It's total garbage. It's better
to just delete it.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH bpf] xdp: Fix handling of devmap in generic XDP
From: kbuild test robot @ 2018-06-13 9:27 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
netdev, Jesper Dangaard Brouer
In-Reply-To: <1528877178-2521-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
Hi Toshiaki,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf/master]
url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/xdp-Fix-handling-of-devmap-in-generic-XDP/20180613-161204
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git master
config: i386-randconfig-a1-201823 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from net//bpf/test_run.c:7:0:
>> include/linux/bpf.h:594:16: warning: 'struct sk_buff' declared inside parameter list
struct bpf_prog *xdp_prog)
^
>> include/linux/bpf.h:594:16: warning: its scope is only this definition or declaration, which is probably not what you want
vim +594 include/linux/bpf.h
591
592 static inline int dev_map_generic_redirect(struct bpf_dtab_netdev *dst,
593 struct sk_buff *skb,
> 594 struct bpf_prog *xdp_prog)
595 {
596 return 0;
597 }
598
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28525 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
From: Kalle Valo @ 2018-06-13 9:56 UTC (permalink / raw)
To: kbuild test robot
Cc: Niklas Cassel, kbuild-all, David S. Miller, ath10k,
linux-wireless, netdev, linux-kernel
In-Reply-To: <201806122228.8vAQXcD6%fengguang.wu@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on ath6kl/ath-next]
> [also build test WARNING on next-20180612]
> [cannot apply to v4.17]
> [if your patch is applied to the wrong git tree, please drop us a note
> to help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Niklas-Cassel/ath10k-do-not-mix-spaces-and-tabs-in-Kconfig/20180612-194241
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> drivers/net/wireless/ath/ath10k/snoc.c:823:5: sparse: symbol
>>> 'ath10k_snoc_get_ce_id_from_irq' was not declared. Should it be
>>> static?
>>> drivers/net/wireless/ath/ath10k/snoc.c:871:6: sparse: symbol
>>> 'ath10k_snoc_init_napi' was not declared. Should it be static?
>
> Please review and possibly fold the followup patch.
There's already a patch pending to fix these:
ath10k: make some functions static
https://patchwork.kernel.org/patch/10440159/
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH] ath10k: ath10k_snoc_get_ce_id_from_irq() can be static
From: Kalle Valo @ 2018-06-13 9:57 UTC (permalink / raw)
To: kbuild test robot
Cc: Niklas Cassel, kbuild-all, David S. Miller, ath10k,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180612145037.GA95182@lkp-ib03>
kbuild test robot <fengguang.wu@intel.com> writes:
> Fixes: aecf55e7df3a ("ath10k: allow ATH10K_SNOC with COMPILE_TEST")
> Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
There's already an identical patch pending:
ath10k: make some functions static
https://patchwork.kernel.org/patch/10440159/
--
Kalle Valo
^ permalink raw reply
* Re: KASAN: out-of-bounds Read in rds_cong_queue_updates (2)
From: Sowmini Varadhan @ 2018-06-13 10:19 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, rds-devel, Santosh Shilimkar
In-Reply-To: <CACT4Y+bM4jA4Ptrdb1x8xVONJOCurcwYKL+kgxFCdk7R4g9Nvw@mail.gmail.com>
On (06/13/18 09:52), Dmitry Vyukov wrote:
> I think this is:
>
> #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
Indeed. We'd had a discussion about getting a dump of threads
using sysrq (or similar), given the challenges around actually
getting a crash dump, is that now possible? That will certainly help.
another missing bit is that we still need the sychronize_net()
in rds_release(). I realize synchronize_net() is sub-optimal for perf,
but leaving this existing hole where races can occur in unexpected
manifestations is not ideal either.
(See https://www.spinics.net/lists/netdev/msg475074.html for earlier
discussion thread)
--Sowmini
^ permalink raw reply
* [PATCH 0/9] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter patches for your net tree:
1) Fix NULL pointer dereference from nf_nat_decode_session() if NAT is
not loaded, from Prashant Bhole.
2) Fix socket extension module autoload.
3) Don't bogusly reject sets with the NFT_SET_EVAL flag set on from
the dynset extension.
4) Fix races with nf_tables module removal and netns exit path,
patches from Florian Westphal.
5) Don't hit BUG_ON if jumpstack goes too deep, instead hit
WARN_ON_ONCE, from Taehee Yoo.
6) Another NULL pointer dereference from ctnetlink, again if NAT is
not loaded, from Florian Westphal.
7) Fix x_tables match list corruption in xt_connmark module removal
path, also from Florian.
8) nf_conncount doesn't properly deal with conntrack zones, hence
garbage collector may get rid of entries in a different zone.
From Yi-Hung Wei.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks.
----------------------------------------------------------------
The following changes since commit 6892286e9c09925780fe2cb6db3585b56b71fe8e:
tcp: Do not reload skb pointer after skb_gro_receive(). (2018-06-11 20:00:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to 21ba8847f857028dc83a0f341e16ecc616e34740:
netfilter: nf_conncount: Fix garbage collection with zones (2018-06-12 20:07:07 +0200)
----------------------------------------------------------------
Florian Westphal (4):
netfilter: nf_tables: fix module unload race
netfilter: nf_tables: close race between netns exit and rmmod
netfilter: ctnetlink: avoid null pointer dereference
netfilter: xt_connmark: fix list corruption on rmmod
Pablo Neira Ayuso (2):
netfilter: nft_socket: fix module autoload
netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
Prashant Bhole (1):
netfilter: fix null-ptr-deref in nf_nat_decode_session
Taehee Yoo (1):
netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()
Yi-Hung Wei (1):
netfilter: nf_conncount: Fix garbage collection with zones
include/linux/netfilter.h | 2 +-
include/net/netfilter/nf_conntrack_count.h | 3 ++-
include/uapi/linux/netfilter/nf_tables.h | 2 +-
net/netfilter/nf_conncount.c | 13 +++++++++----
net/netfilter/nf_conntrack_netlink.c | 3 ++-
net/netfilter/nf_tables_api.c | 25 +++++++++++++++++++------
net/netfilter/nf_tables_core.c | 3 ++-
net/netfilter/nfnetlink.c | 10 +++++++---
net/netfilter/nft_chain_filter.c | 5 +++++
net/netfilter/nft_connlimit.c | 2 +-
net/netfilter/nft_dynset.c | 4 +---
net/netfilter/nft_socket.c | 1 +
net/netfilter/xt_connmark.c | 2 +-
13 files changed, 52 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 1/9] netfilter: fix null-ptr-deref in nf_nat_decode_session
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
From: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Add null check for nat_hook in nf_nat_decode_session()
[ 195.648098] UBSAN: Undefined behaviour in ./include/linux/netfilter.h:348:14
[ 195.651366] BUG: KASAN: null-ptr-deref in __xfrm_policy_check+0x208/0x1d70
[ 195.653888] member access within null pointer of type 'struct nf_nat_hook'
[ 195.653896] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.17.0-rc6+ #5
[ 195.656320] Read of size 8 at addr 0000000000000008 by task ping/2469
[ 195.658715] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 195.658721] Call Trace:
[ 195.661087]
[ 195.669341] <IRQ>
[ 195.670574] dump_stack+0xc6/0x150
[ 195.672156] ? dump_stack_print_info.cold.0+0x1b/0x1b
[ 195.674121] ? ubsan_prologue+0x31/0x92
[ 195.676546] ubsan_epilogue+0x9/0x49
[ 195.678159] handle_null_ptr_deref+0x11a/0x130
[ 195.679800] ? sprint_OID+0x1a0/0x1a0
[ 195.681322] __ubsan_handle_type_mismatch_v1+0xd5/0x11d
[ 195.683146] ? ubsan_prologue+0x92/0x92
[ 195.684642] __xfrm_policy_check+0x18ef/0x1d70
[ 195.686294] ? rt_cache_valid+0x118/0x180
[ 195.687804] ? __xfrm_route_forward+0x410/0x410
[ 195.689463] ? fib_multipath_hash+0x700/0x700
[ 195.691109] ? kvm_sched_clock_read+0x23/0x40
[ 195.692805] ? pvclock_clocksource_read+0xf6/0x280
[ 195.694409] ? graph_lock+0xa0/0xa0
[ 195.695824] ? pvclock_clocksource_read+0xf6/0x280
[ 195.697508] ? pvclock_read_flags+0x80/0x80
[ 195.698981] ? kvm_sched_clock_read+0x23/0x40
[ 195.700347] ? sched_clock+0x5/0x10
[ 195.701525] ? sched_clock_cpu+0x18/0x1a0
[ 195.702846] tcp_v4_rcv+0x1d32/0x1de0
[ 195.704115] ? lock_repin_lock+0x70/0x270
[ 195.707072] ? pvclock_read_flags+0x80/0x80
[ 195.709302] ? tcp_v4_early_demux+0x4b0/0x4b0
[ 195.711833] ? lock_acquire+0x195/0x380
[ 195.714222] ? ip_local_deliver_finish+0xfc/0x770
[ 195.716967] ? raw_rcv+0x2b0/0x2b0
[ 195.718856] ? lock_release+0xa00/0xa00
[ 195.720938] ip_local_deliver_finish+0x1b9/0x770
[...]
Fixes: 2c205dd3981f ("netfilter: add struct nf_nat_hook and use it")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 04551af2ff23..dd2052f0efb7 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -345,7 +345,7 @@ nf_nat_decode_session(struct sk_buff *skb, struct flowi *fl, u_int8_t family)
rcu_read_lock();
nat_hook = rcu_dereference(nf_nat_hook);
- if (nat_hook->decode_session)
+ if (nat_hook && nat_hook->decode_session)
nat_hook->decode_session(skb, fl);
rcu_read_unlock();
#endif
--
2.11.0
^ permalink raw reply related
* [PATCH 2/9] netfilter: nft_socket: fix module autoload
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 665 bytes --]
Add alias definition for module autoload when adding socket rules.
Fixes: 554ced0a6e29 ("netfilter: nf_tables: add support for native socket matching")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/nft_socket.c b/net/netfilter/nft_socket.c
index f28a0b944087..74e1b3bd6954 100644
--- a/net/netfilter/nft_socket.c
+++ b/net/netfilter/nft_socket.c
@@ -142,3 +142,4 @@ module_exit(nft_socket_module_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Máté Eckl");
MODULE_DESCRIPTION("nf_tables socket match module");
+MODULE_ALIAS_NFT_EXPR("socket");
--
2.11.0
^ permalink raw reply related
* [PATCH 3/9] netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
NFT_SET_EVAL is signalling the kernel that this sets can be updated from
the evaluation path, even if there are no expressions attached to the
element. Otherwise, set updates with no expressions fail. Update
description to describe the right semantics.
Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/netfilter/nf_tables.h | 2 +-
net/netfilter/nft_dynset.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index c9bf74b94f37..89438e68dc03 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -266,7 +266,7 @@ enum nft_rule_compat_attributes {
* @NFT_SET_INTERVAL: set contains intervals
* @NFT_SET_MAP: set is used as a dictionary
* @NFT_SET_TIMEOUT: set uses timeouts
- * @NFT_SET_EVAL: set contains expressions for evaluation
+ * @NFT_SET_EVAL: set can be updated from the evaluation path
* @NFT_SET_OBJECT: set contains stateful objects
*/
enum nft_set_flags {
diff --git a/net/netfilter/nft_dynset.c b/net/netfilter/nft_dynset.c
index 4d49529cff61..27d7e4598ab6 100644
--- a/net/netfilter/nft_dynset.c
+++ b/net/netfilter/nft_dynset.c
@@ -203,9 +203,7 @@ static int nft_dynset_init(const struct nft_ctx *ctx,
goto err1;
set->ops->gc_init(set);
}
-
- } else if (set->flags & NFT_SET_EVAL)
- return -EINVAL;
+ }
nft_set_ext_prepare(&priv->tmpl);
nft_set_ext_add_length(&priv->tmpl, NFT_SET_EXT_KEY, set->klen);
--
2.11.0
^ permalink raw reply related
* [PATCH 4/9] netfilter: nf_tables: fix module unload race
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
We must first remove the nfnetlink protocol handler when nf_tables module
is unloaded -- we don't want userspace to submit new change requests once
we've started to tear down nft state.
Furthermore, nfnetlink must not call any subsystem function after
call_batch returned -EAGAIN.
EAGAIN means the subsys mutex was dropped, so its unlikely but possible that
nf_tables subsystem was removed due to 'rmmod nf_tables' on another cpu.
Therefore, we must abort batch completely and not move on to next part of
the batch.
Last, we can't invoke ->abort unless we've checked that the subsystem is
still registered.
Change netns exit path of nf_tables to make sure any incompleted
transaction gets removed on exit.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 12 +++++++++---
net/netfilter/nfnetlink.c | 10 +++++++---
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 7979095b69b0..ae312b31db28 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -6439,7 +6439,7 @@ static void nf_tables_abort_release(struct nft_trans *trans)
kfree(trans);
}
-static int nf_tables_abort(struct net *net, struct sk_buff *skb)
+static int __nf_tables_abort(struct net *net)
{
struct nft_trans *trans, *next;
struct nft_trans_elem *te;
@@ -6555,6 +6555,11 @@ static void nf_tables_cleanup(struct net *net)
nft_validate_state_update(net, NFT_VALIDATE_SKIP);
}
+static int nf_tables_abort(struct net *net, struct sk_buff *skb)
+{
+ return __nf_tables_abort(net);
+}
+
static bool nf_tables_valid_genid(struct net *net, u32 genid)
{
return net->nft.base_seq == genid;
@@ -7149,9 +7154,10 @@ static int __net_init nf_tables_init_net(struct net *net)
static void __net_exit nf_tables_exit_net(struct net *net)
{
+ if (!list_empty(&net->nft.commit_list))
+ __nf_tables_abort(net);
__nft_release_tables(net);
WARN_ON_ONCE(!list_empty(&net->nft.tables));
- WARN_ON_ONCE(!list_empty(&net->nft.commit_list));
}
static struct pernet_operations nf_tables_net_ops = {
@@ -7193,9 +7199,9 @@ static int __init nf_tables_module_init(void)
static void __exit nf_tables_module_exit(void)
{
- unregister_pernet_subsys(&nf_tables_net_ops);
nfnetlink_subsys_unregister(&nf_tables_subsys);
unregister_netdevice_notifier(&nf_tables_flowtable_notifier);
+ unregister_pernet_subsys(&nf_tables_net_ops);
rcu_barrier();
nf_tables_core_module_exit();
kfree(info);
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 4d0da7042aff..e1b6be29848d 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -429,7 +429,7 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
*/
if (err == -EAGAIN) {
status |= NFNL_BATCH_REPLAY;
- goto next;
+ goto done;
}
}
ack:
@@ -456,7 +456,7 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
if (err)
status |= NFNL_BATCH_FAILURE;
}
-next:
+
msglen = NLMSG_ALIGN(nlh->nlmsg_len);
if (msglen > skb->len)
msglen = skb->len;
@@ -464,7 +464,11 @@ static void nfnetlink_rcv_batch(struct sk_buff *skb, struct nlmsghdr *nlh,
}
done:
if (status & NFNL_BATCH_REPLAY) {
- ss->abort(net, oskb);
+ const struct nfnetlink_subsystem *ss2;
+
+ ss2 = nfnl_dereference_protected(subsys_id);
+ if (ss2 == ss)
+ ss->abort(net, oskb);
nfnl_err_reset(&err_list);
nfnl_unlock(subsys_id);
kfree_skb(skb);
--
2.11.0
^ permalink raw reply related
* [PATCH 5/9] netfilter: nf_tables: close race between netns exit and rmmod
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
If net namespace is exiting while nf_tables module is being removed
we can oops:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: nf_tables_flowtable_event+0x43/0xf0 [nf_tables]
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Modules linked in: nf_tables(-) nfnetlink [..]
unregister_netdevice_notifier+0xdd/0x130
nf_tables_module_exit+0x24/0x3a [nf_tables]
SyS_delete_module+0x1c5/0x240
do_syscall_64+0x74/0x190
Avoid this by attempting to take reference on the net namespace from
the notifiers. If it fails the namespace is exiting already, and nft
core is taking care of cleanup work.
We also need to make sure the netdev hook type gets removed
before netns ops removal, else notifier might be invoked with device
event for a netns where net->nft was never initialised (because
pernet ops was removed beforehand).
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 13 ++++++++++---
net/netfilter/nft_chain_filter.c | 5 +++++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index ae312b31db28..d23a5c269c44 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -5837,18 +5837,23 @@ static int nf_tables_flowtable_event(struct notifier_block *this,
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct nft_flowtable *flowtable;
struct nft_table *table;
+ struct net *net;
if (event != NETDEV_UNREGISTER)
return 0;
+ net = maybe_get_net(dev_net(dev));
+ if (!net)
+ return 0;
+
nfnl_lock(NFNL_SUBSYS_NFTABLES);
- list_for_each_entry(table, &dev_net(dev)->nft.tables, list) {
+ list_for_each_entry(table, &net->nft.tables, list) {
list_for_each_entry(flowtable, &table->flowtables, list) {
nft_flowtable_event(event, dev, flowtable);
}
}
nfnl_unlock(NFNL_SUBSYS_NFTABLES);
-
+ put_net(net);
return NOTIFY_DONE;
}
@@ -7154,9 +7159,11 @@ static int __net_init nf_tables_init_net(struct net *net)
static void __net_exit nf_tables_exit_net(struct net *net)
{
+ nfnl_lock(NFNL_SUBSYS_NFTABLES);
if (!list_empty(&net->nft.commit_list))
__nf_tables_abort(net);
__nft_release_tables(net);
+ nfnl_unlock(NFNL_SUBSYS_NFTABLES);
WARN_ON_ONCE(!list_empty(&net->nft.tables));
}
@@ -7201,11 +7208,11 @@ static void __exit nf_tables_module_exit(void)
{
nfnetlink_subsys_unregister(&nf_tables_subsys);
unregister_netdevice_notifier(&nf_tables_flowtable_notifier);
+ nft_chain_filter_fini();
unregister_pernet_subsys(&nf_tables_net_ops);
rcu_barrier();
nf_tables_core_module_exit();
kfree(info);
- nft_chain_filter_fini();
}
module_init(nf_tables_module_init);
diff --git a/net/netfilter/nft_chain_filter.c b/net/netfilter/nft_chain_filter.c
index 84c902477a91..d21834bed805 100644
--- a/net/netfilter/nft_chain_filter.c
+++ b/net/netfilter/nft_chain_filter.c
@@ -318,6 +318,10 @@ static int nf_tables_netdev_event(struct notifier_block *this,
event != NETDEV_CHANGENAME)
return NOTIFY_DONE;
+ ctx.net = maybe_get_net(ctx.net);
+ if (!ctx.net)
+ return NOTIFY_DONE;
+
nfnl_lock(NFNL_SUBSYS_NFTABLES);
list_for_each_entry(table, &ctx.net->nft.tables, list) {
if (table->family != NFPROTO_NETDEV)
@@ -334,6 +338,7 @@ static int nf_tables_netdev_event(struct notifier_block *this,
}
}
nfnl_unlock(NFNL_SUBSYS_NFTABLES);
+ put_net(ctx.net);
return NOTIFY_DONE;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 6/9] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
From: Taehee Yoo <ap420073@gmail.com>
When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain
crashes. But there is no need to crash hard here.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_core.c b/net/netfilter/nf_tables_core.c
index deff10adef9c..8de912ca53d3 100644
--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@ -183,7 +183,8 @@ nft_do_chain(struct nft_pktinfo *pkt, void *priv)
switch (regs.verdict.code) {
case NFT_JUMP:
- BUG_ON(stackptr >= NFT_JUMP_STACK_SIZE);
+ if (WARN_ON_ONCE(stackptr >= NFT_JUMP_STACK_SIZE))
+ return NF_DROP;
jumpstack[stackptr].chain = chain;
jumpstack[stackptr].rules = rules + 1;
stackptr++;
--
2.11.0
^ permalink raw reply related
* [PATCH 7/9] netfilter: ctnetlink: avoid null pointer dereference
From: Pablo Neira Ayuso @ 2018-06-13 10:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180613105700.12894-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Dan Carpenter points out that deref occurs after NULL check, we should
re-fetch the pointer and check that instead.
Fixes: 2c205dd3981f7 ("netfilter: add struct nf_nat_hook and use it")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_netlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 39327a42879f..20a2e37c76d1 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1446,7 +1446,8 @@ ctnetlink_parse_nat_setup(struct nf_conn *ct,
}
nfnl_lock(NFNL_SUBSYS_CTNETLINK);
rcu_read_lock();
- if (nat_hook->parse_nat_setup)
+ nat_hook = rcu_dereference(nf_nat_hook);
+ if (nat_hook)
return -EAGAIN;
#endif
return -EOPNOTSUPP;
--
2.11.0
^ permalink raw reply related
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