* Re: [PATCH 1/2] net/fsl_pq_mdio: Allow explicit speficition of TBIPA address
From: David Miller @ 2018-04-08 16:45 UTC (permalink / raw)
To: esben.haabendal
Cc: netdev, eha, claudiu.manoil, robh+dt, mark.rutland, garsilva,
devicetree, linux-kernel
In-Reply-To: <20180406123836.12019-1-esben.haabendal@gmail.com>
From: Esben Haabendal <esben.haabendal@gmail.com>
Date: Fri, 6 Apr 2018 14:38:34 +0200
> From: Esben Haabendal <eha@deif.com>
>
> This introduces a simpler and generic method for for finding (and mapping)
> the TBIPA register.
>
> Instead of relying of complicated logic for finding the TBIPA register
> address based on the MDIO or MII register block base
> address, which even in some cases relies on undocumented shadow registers,
> a second "reg" entry for the mdio bus devicetree node specifies the TBIPA
> register.
>
> Backwards compatibility is kept, as the existing logic is applied when
> only a single "reg" mapping is specified.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4] net: thunderx: rework mac addresses list to u64 array
From: David Miller @ 2018-04-08 16:42 UTC (permalink / raw)
To: Vadim.Lomovtsev
Cc: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, dnelson, robin.murphy, hch, gustavo,
Vadim.Lomovtsev
In-Reply-To: <20180406195354.16037-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Date: Fri, 6 Apr 2018 12:53:54 -0700
> @@ -1929,7 +1929,7 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
> work.work);
> struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
> union nic_mbx mbx = {};
> - struct xcast_addr *xaddr, *next;
> + int idx = 0;
No need to initialize idx.
> + for (idx = 0; idx < vf_work->mc->count; idx++) {
As it is always explicitly initialized at, and only used inside of,
this loop.
^ permalink raw reply
* Re: [PATCH net 0/5] ibmvnic: Fix driver reset and DMA bugs
From: David Miller @ 2018-04-08 16:40 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, jallen, nfont
In-Reply-To: <1523057826-5262-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 6 Apr 2018 18:37:01 -0500
> This patch series introduces some fixes to the driver reset
> routines and a patch that fixes mistakes caught by the kernel
> DMA debugger.
>
> The reset fixes include a fix to reset TX queue counters properly
> after a reset as well as updates to driver reset error-handling code.
> It also provides updates to the reset handling routine for redundant
> backing VF failover and partition migration cases.
Series applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH net 0/8] net: fix uninit-values in networking stack
From: Eric Dumazet @ 2018-04-08 16:38 UTC (permalink / raw)
To: David Miller, edumazet; +Cc: netdev
In-Reply-To: <20180407.224025.1923207101579714958.davem@davemloft.net>
On 04/07/2018 07:40 PM, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Sat, 7 Apr 2018 13:42:35 -0700
>
>> It seems syzbot got new features enabled, and fired some interesting
>> reports. Oh well.
>
> Series applied, however in patch #7 the condition syzbot detects
> cannot happen.
>
> In all code paths that lead to __mkroute_output() with res->type
> uninitialized, __mkroute_output() will reassign the local variable
> 'type' before reading it.
Well, we have :
u16 type = res->type;
...
if (ipv4_is_lbcast(fl4->daddr))
type = RTN_BROADCAST;
else if (ipv4_is_multicast(fl4->daddr))
type = RTN_MULTICAST;
else if (ipv4_is_zeronet(fl4->daddr))
return ERR_PTR(-EINVAL);
...
if (type == RTN_BROADCAST) { /* This is where KMSAN complained */
So it looks like type could have been random at this point.
>
> Furthermore, by doing a full structure initialization lots of
> unrelated things will be initialized now as well.
fib_result is 40 bytes on 64bit arches.
>
> We explicitly are only setting up the "inputs" of the fib_result
> object before we call fib_lookup(). The prefixlen and other members
> have no business being initialized there.
>
Yep
We might put all inputs at the beginning of the structure,
and output at the end. then replace sizeof() by offsetof(),
but this looks a bit convoluted and maybe risky.
^ permalink raw reply
* Re: [Patch net] tipc: use the right skb in tipc_sk_fill_sock_diag()
From: David Miller @ 2018-04-08 16:34 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, jon.maloy, ying.xue
In-Reply-To: <20180407015452.26636-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 6 Apr 2018 18:54:52 -0700
> Commit 4b2e6877b879 ("tipc: Fix namespace violation in tipc_sk_fill_sock_diag")
> tried to fix the crash but failed, the crash is still 100% reproducible
> with it.
>
> In tipc_sk_fill_sock_diag(), skb is the diag dump we are filling, it is not
> correct to retrieve its NETLINK_CB(), instead, like other protocol diag,
> we should use NETLINK_CB(cb->skb).sk here.
>
> Reported-by: <syzbot+326e587eff1074657718@syzkaller.appspotmail.com>
> Fixes: 4b2e6877b879 ("tipc: Fix namespace violation in tipc_sk_fill_sock_diag")
> Fixes: c30b70deb5f4 (tipc: implement socket diagnostics for AF_TIPC)
> Cc: GhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
> Cc: Jon Maloy <jon.maloy@ericsson.com>
> Cc: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: David Miller @ 2018-04-08 16:32 UTC (permalink / raw)
To: loseweigh
Cc: dsahern, jiri, si-wei.liu, mst, stephen, alexander.h.duyck,
jesse.brandeburg, kubakici, jasowang, sridhar.samudrala, netdev,
virtualization, virtio-dev
In-Reply-To: <CADGSJ206RKi704uoLe3xVs6PyWpURPLb75OPCM_YO9DfnnEzpw@mail.gmail.com>
From: Siwei Liu <loseweigh@gmail.com>
Date: Fri, 6 Apr 2018 19:32:05 -0700
> And I assume everyone here understands the use case for live
> migration (in the context of providing cloud service) is very
> different, and we have to hide the netdevs. If not, I'm more than
> happy to clarify.
I think you still need to clarify.
netdevs are netdevs. If they have special attributes, mark them as
such and the tools base their actions upon that.
"Hiding", or changing classes, doesn't make any sense to me still.
^ permalink raw reply
* Re: [PATCH net] sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6
From: David Miller @ 2018-04-08 16:30 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, vyasevich, nhorman
In-Reply-To: <20180408145208.228542-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 8 Apr 2018 07:52:08 -0700
> Check must happen before call to ipv6_addr_v4mapped()
>
> syzbot report was :
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: possible deadlock in perf_event_detach_bpf_prog
From: Y Song @ 2018-04-08 15:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: syzbot, Alexei Starovoitov, linux-kernel, mingo, netdev, rostedt,
syzkaller-bugs
In-Reply-To: <439cb956-9f4d-b972-07f2-40080b25ecbf@iogearbox.net>
On Thu, Mar 29, 2018 at 2:18 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/29/2018 11:04 PM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +0000)
>> Linux 4.16-rc7
>> syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=dc5ca0e4c9bfafaf2bae
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output: https://syzkaller.appspot.com/x/log.txt?id=4742532743299072
>> Kernel config: https://syzkaller.appspot.com/x/.config?id=-8440362230543204781
>> compiler: gcc (GCC) 7.1.1 20170620
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+dc5ca0e4c9bfafaf2bae@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 circular locking dependency detected
>> 4.16.0-rc7+ #3 Not tainted
>> ------------------------------------------------------
>> syz-executor7/24531 is trying to acquire lock:
>> (bpf_event_mutex){+.+.}, at: [<000000008a849b07>] perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854
>>
>> but task is already holding lock:
>> (&mm->mmap_sem){++++}, at: [<0000000038768f87>] vm_mmap_pgoff+0x198/0x280 mm/util.c:353
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #1 (&mm->mmap_sem){++++}:
>> __might_fault+0x13a/0x1d0 mm/memory.c:4571
>> _copy_to_user+0x2c/0xc0 lib/usercopy.c:25
>> copy_to_user include/linux/uaccess.h:155 [inline]
>> bpf_prog_array_copy_info+0xf2/0x1c0 kernel/bpf/core.c:1694
>> perf_event_query_prog_array+0x1c7/0x2c0 kernel/trace/bpf_trace.c:891
>
> Looks like we should move the two copy_to_user() outside of
> bpf_event_mutex section to avoid the deadlock.
This is introduced by one of my previous patches. The above suggested fix
makes sense. I will craft a patch and send to the mailing list for bpf branch
soon.
>
>> _perf_ioctl kernel/events/core.c:4750 [inline]
>> perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4770
>> vfs_ioctl fs/ioctl.c:46 [inline]
>> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>> SYSC_ioctl fs/ioctl.c:701 [inline]
>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>>
>> -> #0 (bpf_event_mutex){+.+.}:
>> 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
>> perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854
>> perf_event_free_bpf_prog kernel/events/core.c:8147 [inline]
>> _free_event+0xbdb/0x10f0 kernel/events/core.c:4116
>> put_event+0x24/0x30 kernel/events/core.c:4204
>> perf_mmap_close+0x60d/0x1010 kernel/events/core.c:5172
>> remove_vma+0xb4/0x1b0 mm/mmap.c:172
>> remove_vma_list mm/mmap.c:2490 [inline]
>> do_munmap+0x82a/0xdf0 mm/mmap.c:2731
>> mmap_region+0x59e/0x15a0 mm/mmap.c:1646
>> do_mmap+0x6c0/0xe00 mm/mmap.c:1483
>> do_mmap_pgoff include/linux/mm.h:2223 [inline]
>> vm_mmap_pgoff+0x1de/0x280 mm/util.c:355
>> SYSC_mmap_pgoff mm/mmap.c:1533 [inline]
>> SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491
>> SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>> SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
>> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>>
>> other info that might help us debug this:
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(&mm->mmap_sem);
>> lock(bpf_event_mutex);
>> lock(&mm->mmap_sem);
>> lock(bpf_event_mutex);
>>
>> *** DEADLOCK ***
>>
>> 1 lock held by syz-executor7/24531:
>> #0: (&mm->mmap_sem){++++}, at: [<0000000038768f87>] vm_mmap_pgoff+0x198/0x280 mm/util.c:353
>>
>> stack backtrace:
>> CPU: 0 PID: 24531 Comm: syz-executor7 Not tainted 4.16.0-rc7+ #3
>> 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_circular_bug.isra.38+0x2cd/0x2dc kernel/locking/lockdep.c:1223
>> check_prev_add kernel/locking/lockdep.c:1863 [inline]
>> check_prevs_add kernel/locking/lockdep.c:1976 [inline]
>> validate_chain kernel/locking/lockdep.c:2417 [inline]
>> __lock_acquire+0x30a8/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
>> perf_event_detach_bpf_prog+0x92/0x3d0 kernel/trace/bpf_trace.c:854
>> perf_event_free_bpf_prog kernel/events/core.c:8147 [inline]
>> _free_event+0xbdb/0x10f0 kernel/events/core.c:4116
>> put_event+0x24/0x30 kernel/events/core.c:4204
>> perf_mmap_close+0x60d/0x1010 kernel/events/core.c:5172
>> remove_vma+0xb4/0x1b0 mm/mmap.c:172
>> remove_vma_list mm/mmap.c:2490 [inline]
>> do_munmap+0x82a/0xdf0 mm/mmap.c:2731
>> mmap_region+0x59e/0x15a0 mm/mmap.c:1646
>> do_mmap+0x6c0/0xe00 mm/mmap.c:1483
>> do_mmap_pgoff include/linux/mm.h:2223 [inline]
>> vm_mmap_pgoff+0x1de/0x280 mm/util.c:355
>> SYSC_mmap_pgoff mm/mmap.c:1533 [inline]
>> SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491
>> SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>> SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
>> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>> RIP: 0033:0x454889
>> RSP: 002b:00007f5f44fdac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
>> RAX: ffffffffffffffda RBX: 00007f5f44fdb6d4 RCX: 0000000000454889
>> RDX: 0000000000000000 RSI: 0000000000002000 RDI: 0000000020f1f000
>> RBP: 000000000072c010 R08: 0000000000000014 R09: 0000000000000000
>> R10: 0000000000000011 R11: 0000000000000246 R12: 00000000ffffffff
>> R13: 00000000000003f4 R14: 00000000006f7f80 R15: 0000000000000002
>> bond0 (unregistering): Released all slaves
>> IPVS: ftp: loaded support on port[0] = 21
>> IPv6: ADDRCONF(NETDEV_UP): bridge0: link is not ready
>> IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
>> 8021q: adding VLAN 0 to HW filter on device bond0
>> IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
>> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>> kernel msg: ebtables bug: please report to author: Wrong len argument
>>
>>
>> ---
>> 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
>> 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
* KMSAN: uninit-value in tipc_subscrb_rcv_cb
From: syzbot @ 2018-04-08 15:38 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=75e6e042c5bbf691fc82
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5784467448791040
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329060) (llvm/trunk 329054)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+75e6e042c5bbf691fc82@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: KMSAN: uninit-value in htohl net/tipc/subscr.c:66 [inline]
BUG: KMSAN: uninit-value in tipc_subscrb_rcv_cb+0x418/0xe80
net/tipc/subscr.c:339
CPU: 1 PID: 5017 Comm: kworker/u4:6 Not tainted 4.16.0+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: tipc_rcv tipc_recv_work
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
htohl net/tipc/subscr.c:66 [inline]
tipc_subscrb_rcv_cb+0x418/0xe80 net/tipc/subscr.c:339
tipc_receive_from_sock+0x64c/0x800 net/tipc/server.c:271
tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
tipc_receive_from_sock+0x15c/0x800 net/tipc/server.c:253
tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 5017 Comm: kworker/u4:6 Tainted: G B 4.16.0+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: tipc_rcv tipc_recv_work
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
panic+0x39d/0x940 kernel/panic.c:183
kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
htohl net/tipc/subscr.c:66 [inline]
tipc_subscrb_rcv_cb+0x418/0xe80 net/tipc/subscr.c:339
tipc_receive_from_sock+0x64c/0x800 net/tipc/server.c:271
tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406
Shutting down cpus with NMI
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
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
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
* [PATCH net] sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6
From: Eric Dumazet @ 2018-04-08 14:52 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Vlad Yasevich, Neil Horman
Check must happen before call to ipv6_addr_v4mapped()
syzbot report was :
BUG: KMSAN: uninit-value in sctp_sockaddr_af net/sctp/socket.c:359 [inline]
BUG: KMSAN: uninit-value in sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
CPU: 0 PID: 3576 Comm: syzkaller968804 Not tainted 4.16.0+ #82
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
sctp_sockaddr_af net/sctp/socket.c:359 [inline]
sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
sctp_bind+0x149/0x190 net/sctp/socket.c:332
inet6_bind+0x1fd/0x1820 net/ipv6/af_inet6.c:293
SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
SyS_bind+0x54/0x80 net/socket.c:1460
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fd49
RSP: 002b:00007ffe99df3d28 EFLAGS: 00000213 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----address@SYSC_bind
Variable was created at:
SYSC_bind+0x6f/0x4b0 net/socket.c:1461
SyS_bind+0x54/0x80 net/socket.c:1460
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/sctp/socket.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 7a10ae3c3d8293abecd955ff6a5a19e60dcc6f95..eb712df7156eda7124cd88b4034359b088c2c475 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -357,11 +357,14 @@ static struct sctp_af *sctp_sockaddr_af(struct sctp_sock *opt,
if (!opt->pf->af_supported(addr->sa.sa_family, opt))
return NULL;
- /* V4 mapped address are really of AF_INET family */
- if (addr->sa.sa_family == AF_INET6 &&
- ipv6_addr_v4mapped(&addr->v6.sin6_addr) &&
- !opt->pf->af_supported(AF_INET, opt))
- return NULL;
+ if (addr->sa.sa_family == AF_INET6) {
+ if (len < SIN6_LEN_RFC2133)
+ return NULL;
+ /* V4 mapped address are really of AF_INET family */
+ if (ipv6_addr_v4mapped(&addr->v6.sin6_addr) &&
+ !opt->pf->af_supported(AF_INET, opt))
+ return NULL;
+ }
/* If we get this far, af is valid. */
af = sctp_get_af_specific(addr->sa.sa_family);
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* Re: [PATCH v2 net] net: dsa: Discard frames from unused ports
From: David Miller @ 2018-04-08 14:35 UTC (permalink / raw)
To: andrew; +Cc: netdev, f.fainelli, vivien.didelot
In-Reply-To: <1523126260-15559-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 7 Apr 2018 20:37:40 +0200
> The Marvell switches under some conditions will pass a frame to the
> host with the port being the CPU port. Such frames are invalid, and
> should be dropped. Not dropping them can result in a crash when
> incrementing the receive statistics for an invalid port.
>
> Reported-by: Chris Healy <cphealy@gmail.com>
> Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> v2:
> Use an earlier revision for the fixes tag.
> Add unlikely annotation
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: do not leak kernel memory to user space
From: David Miller @ 2018-04-08 14:32 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180408001522.110590-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 7 Apr 2018 17:15:22 -0700
> syzbot produced a nice report [1]
>
> Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
> to user space, because sin_zero (padding field) was not properly cleared.
...
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] net: phy: marvell10g: add thermal hwmon device
From: Guenter Roeck @ 2018-04-08 14:04 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Lunn, Florian Fainelli, netdev
In-Reply-To: <E1f3II5-00077a-R3@rmk-PC.armlinux.org.uk>
On Tue, Apr 03, 2018 at 10:31:45AM +0100, Russell King wrote:
> Add a thermal monitoring device for the Marvell 88x3310, which updates
> once a second. We also need to hook into the suspend/resume mechanism
> to ensure that the thermal monitoring is reconfigured when we resume.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> v2: update to apply to net-next
>
> drivers/net/phy/marvell10g.c | 184 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 182 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> index 8a0bd98fdec7..db9d66781da6 100644
> --- a/drivers/net/phy/marvell10g.c
> +++ b/drivers/net/phy/marvell10g.c
> @@ -21,8 +21,10 @@
> * If both the fiber and copper ports are connected, the first to gain
> * link takes priority and the other port is completely locked out.
> */
> -#include <linux/phy.h>
> +#include <linux/ctype.h>
> +#include <linux/hwmon.h>
> #include <linux/marvell_phy.h>
> +#include <linux/phy.h>
>
> enum {
> MV_PCS_BASE_T = 0x0000,
> @@ -40,6 +42,19 @@ enum {
> */
> MV_AN_CTRL1000 = 0x8000, /* 1000base-T control register */
> MV_AN_STAT1000 = 0x8001, /* 1000base-T status register */
> +
> + /* Vendor2 MMD registers */
> + MV_V2_TEMP_CTRL = 0xf08a,
> + MV_V2_TEMP_CTRL_MASK = 0xc000,
> + MV_V2_TEMP_CTRL_SAMPLE = 0x0000,
> + MV_V2_TEMP_CTRL_DISABLE = 0xc000,
> + MV_V2_TEMP = 0xf08c,
> + MV_V2_TEMP_UNKNOWN = 0x9600, /* unknown function */
> +};
> +
> +struct mv3310_priv {
> + struct device *hwmon_dev;
> + char *hwmon_name;
> };
>
> static int mv3310_modify(struct phy_device *phydev, int devad, u16 reg,
> @@ -60,17 +75,180 @@ static int mv3310_modify(struct phy_device *phydev, int devad, u16 reg,
> return ret < 0 ? ret : 1;
> }
>
> +#ifdef CONFIG_HWMON
> +static umode_t mv3310_hwmon_is_visible(const void *data,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + if (type == hwmon_chip && attr == hwmon_chip_update_interval)
> + return 0444;
> + if (type == hwmon_temp && attr == hwmon_temp_input)
> + return 0444;
> + return 0;
> +}
> +
> +static int mv3310_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *value)
> +{
> + struct phy_device *phydev = dev_get_drvdata(dev);
> + int temp;
> +
> + if (type == hwmon_chip && attr == hwmon_chip_update_interval) {
> + *value = MSEC_PER_SEC;
The update_interval attribute is supposed to be used for setting an update
interval in the chip. Having it return a constant doesn't really serve a useful
purpose.
Guenter
> + return 0;
> + }
> +
> + if (type == hwmon_temp && attr == hwmon_temp_input) {
> + temp = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_TEMP);
> + if (temp < 0)
> + return temp;
> +
> + *value = ((temp & 0xff) - 75) * 1000;
> +
> + return 0;
> + }
> +
> + return -EOPNOTSUPP;
> +}
> +
> +static const struct hwmon_ops mv3310_hwmon_ops = {
> + .is_visible = mv3310_hwmon_is_visible,
> + .read = mv3310_hwmon_read,
> +};
> +
> +static u32 mv3310_hwmon_chip_config[] = {
> + HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL,
> + 0,
> +};
> +
> +static const struct hwmon_channel_info mv3310_hwmon_chip = {
> + .type = hwmon_chip,
> + .config = mv3310_hwmon_chip_config,
> +};
> +
> +static u32 mv3310_hwmon_temp_config[] = {
> + HWMON_T_INPUT,
> + 0,
> +};
> +
> +static const struct hwmon_channel_info mv3310_hwmon_temp = {
> + .type = hwmon_temp,
> + .config = mv3310_hwmon_temp_config,
> +};
> +
> +static const struct hwmon_channel_info *mv3310_hwmon_info[] = {
> + &mv3310_hwmon_chip,
> + &mv3310_hwmon_temp,
> + NULL,
> +};
> +
> +static const struct hwmon_chip_info mv3310_hwmon_chip_info = {
> + .ops = &mv3310_hwmon_ops,
> + .info = mv3310_hwmon_info,
> +};
> +
> +static int mv3310_hwmon_config(struct phy_device *phydev, bool enable)
> +{
> + u16 val;
> + int ret;
> +
> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, MV_V2_TEMP,
> + MV_V2_TEMP_UNKNOWN);
> + if (ret < 0)
> + return ret;
> +
> + val = enable ? MV_V2_TEMP_CTRL_SAMPLE : MV_V2_TEMP_CTRL_DISABLE;
> + ret = mv3310_modify(phydev, MDIO_MMD_VEND2, MV_V2_TEMP_CTRL,
> + MV_V2_TEMP_CTRL_MASK, val);
> +
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void mv3310_hwmon_disable(void *data)
> +{
> + struct phy_device *phydev = data;
> +
> + mv3310_hwmon_config(phydev, false);
> +}
> +
> +static int mv3310_hwmon_probe(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
> + int i, j, ret;
> +
> + priv->hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
> + if (!priv->hwmon_name)
> + return -ENODEV;
> +
> + for (i = j = 0; priv->hwmon_name[i]; i++) {
> + if (isalnum(priv->hwmon_name[i])) {
> + if (i != j)
> + priv->hwmon_name[j] = priv->hwmon_name[i];
> + j++;
> + }
> + }
> + priv->hwmon_name[j] = '\0';
> +
> + ret = mv3310_hwmon_config(phydev, true);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, mv3310_hwmon_disable, phydev);
> + if (ret)
> + return ret;
> +
> + priv->hwmon_dev = devm_hwmon_device_register_with_info(dev,
> + priv->hwmon_name, phydev,
> + &mv3310_hwmon_chip_info, NULL);
> +
> + return PTR_ERR_OR_ZERO(priv->hwmon_dev);
> +}
> +#else
> +static inline int mv3310_hwmon_config(struct phy_device *phydev, bool enable)
> +{
> + return 0;
> +}
> +
> +static int mv3310_hwmon_probe(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +#endif
> +
> static int mv3310_probe(struct phy_device *phydev)
> {
> + struct mv3310_priv *priv;
> u32 mmd_mask = MDIO_DEVS_PMAPMD | MDIO_DEVS_AN;
> + int ret;
>
> if (!phydev->is_c45 ||
> (phydev->c45_ids.devices_in_package & mmd_mask) != mmd_mask)
> return -ENODEV;
>
> + priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&phydev->mdio.dev, priv);
> +
> + ret = mv3310_hwmon_probe(phydev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int mv3310_suspend(struct phy_device *phydev)
> +{
> return 0;
> }
>
> +static int mv3310_resume(struct phy_device *phydev)
> +{
> + return mv3310_hwmon_config(phydev, true);
> +}
> +
> static int mv3310_config_init(struct phy_device *phydev)
> {
> __ETHTOOL_DECLARE_LINK_MODE_MASK(supported) = { 0, };
> @@ -367,9 +545,11 @@ static struct phy_driver mv3310_drivers[] = {
> SUPPORTED_FIBRE |
> SUPPORTED_10000baseT_Full |
> SUPPORTED_Backplane,
> - .probe = mv3310_probe,
> .soft_reset = gen10g_no_soft_reset,
> .config_init = mv3310_config_init,
> + .probe = mv3310_probe,
> + .suspend = mv3310_suspend,
> + .resume = mv3310_resume,
> .config_aneg = mv3310_config_aneg,
> .aneg_done = mv3310_aneg_done,
> .read_status = mv3310_read_status,
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy
From: Mickaël Salaün @ 2018-04-08 13:13 UTC (permalink / raw)
To: Andy Lutomirski, Alexei Starovoitov, Daniel Borkmann
Cc: LKML, Alexei Starovoitov, Arnaldo Carvalho de Melo,
Casey Schaufler, David Drysdale, David S . Miller,
Eric W . Biederman, Jann Horn, Jonathan Corbet, Michael Kerrisk,
Kees Cook, Paul Moore, Sargun Dhillon, Serge E . Hallyn,
Shuah Khan, Tejun Heo, Thomas Graf, Tycho Andersen, Will Drewry,
Kernel Hardening, Linux API
In-Reply-To: <ab8dda73-4a6e-4e10-cda0-3e91c5019a63@digikod.net>
[-- Attachment #1.1: Type: text/plain, Size: 18229 bytes --]
On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
>
> On 27/02/2018 17:39, Andy Lutomirski wrote:
>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>>> On Tue, Feb 27, 2018 at 05:20:55AM +0000, Andy Lutomirski wrote:
>>>> On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov
>>>> <alexei.starovoitov@gmail.com> wrote:
>>>>> On Tue, Feb 27, 2018 at 04:40:34AM +0000, Andy Lutomirski wrote:
>>>>>> On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov
>>>>>> <alexei.starovoitov@gmail.com> wrote:
>>>>>>> On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
>>>>>>>> The seccomp(2) syscall can be used by a task to apply a Landlock program
>>>>>>>> to itself. As a seccomp filter, a Landlock program is enforced for the
>>>>>>>> current task and all its future children. A program is immutable and a
>>>>>>>> task can only add new restricting programs to itself, forming a list of
>>>>>>>> programss.
>>>>>>>>
>>>>>>>> A Landlock program is tied to a Landlock hook. If the action on a kernel
>>>>>>>> object is allowed by the other Linux security mechanisms (e.g. DAC,
>>>>>>>> capabilities, other LSM), then a Landlock hook related to this kind of
>>>>>>>> object is triggered. The list of programs for this hook is then
>>>>>>>> evaluated. Each program return a 32-bit value which can deny the action
>>>>>>>> on a kernel object with a non-zero value. If every programs of the list
>>>>>>>> return zero, then the action on the object is allowed.
>>>>>>>>
>>>>>>>> Multiple Landlock programs can be chained to share a 64-bits value for a
>>>>>>>> call chain (e.g. evaluating multiple elements of a file path). This
>>>>>>>> chaining is restricted when a process construct this chain by loading a
>>>>>>>> program, but additional checks are performed when it requests to apply
>>>>>>>> this chain of programs to itself. The restrictions ensure that it is
>>>>>>>> not possible to call multiple programs in a way that would imply to
>>>>>>>> handle multiple shared values (i.e. cookies) for one chain. For now,
>>>>>>>> only a fs_pick program can be chained to the same type of program,
>>>>>>>> because it may make sense if they have different triggers (cf. next
>>>>>>>> commits). This restrictions still allows to reuse Landlock programs in
>>>>>>>> a safe way (e.g. use the same loaded fs_walk program with multiple
>>>>>>>> chains of fs_pick programs).
>>>>>>>>
>>>>>>>> Signed-off-by: Mickaël Salaün <mic@digikod.net>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> +struct landlock_prog_set *landlock_prepend_prog(
>>>>>>>> + struct landlock_prog_set *current_prog_set,
>>>>>>>> + struct bpf_prog *prog)
>>>>>>>> +{
>>>>>>>> + struct landlock_prog_set *new_prog_set = current_prog_set;
>>>>>>>> + unsigned long pages;
>>>>>>>> + int err;
>>>>>>>> + size_t i;
>>>>>>>> + struct landlock_prog_set tmp_prog_set = {};
>>>>>>>> +
>>>>>>>> + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
>>>>>>>> + return ERR_PTR(-EINVAL);
>>>>>>>> +
>>>>>>>> + /* validate memory size allocation */
>>>>>>>> + pages = prog->pages;
>>>>>>>> + if (current_prog_set) {
>>>>>>>> + size_t i;
>>>>>>>> +
>>>>>>>> + for (i = 0; i < ARRAY_SIZE(current_prog_set->programs); i++) {
>>>>>>>> + struct landlock_prog_list *walker_p;
>>>>>>>> +
>>>>>>>> + for (walker_p = current_prog_set->programs[i];
>>>>>>>> + walker_p; walker_p = walker_p->prev)
>>>>>>>> + pages += walker_p->prog->pages;
>>>>>>>> + }
>>>>>>>> + /* count a struct landlock_prog_set if we need to allocate one */
>>>>>>>> + if (refcount_read(¤t_prog_set->usage) != 1)
>>>>>>>> + pages += round_up(sizeof(*current_prog_set), PAGE_SIZE)
>>>>>>>> + / PAGE_SIZE;
>>>>>>>> + }
>>>>>>>> + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
>>>>>>>> + return ERR_PTR(-E2BIG);
>>>>>>>> +
>>>>>>>> + /* ensure early that we can allocate enough memory for the new
>>>>>>>> + * prog_lists */
>>>>>>>> + err = store_landlock_prog(&tmp_prog_set, current_prog_set, prog);
>>>>>>>> + if (err)
>>>>>>>> + return ERR_PTR(err);
>>>>>>>> +
>>>>>>>> + /*
>>>>>>>> + * Each task_struct points to an array of prog list pointers. These
>>>>>>>> + * tables are duplicated when additions are made (which means each
>>>>>>>> + * table needs to be refcounted for the processes using it). When a new
>>>>>>>> + * table is created, all the refcounters on the prog_list are bumped (to
>>>>>>>> + * track each table that references the prog). When a new prog is
>>>>>>>> + * added, it's just prepended to the list for the new table to point
>>>>>>>> + * at.
>>>>>>>> + *
>>>>>>>> + * Manage all the possible errors before this step to not uselessly
>>>>>>>> + * duplicate current_prog_set and avoid a rollback.
>>>>>>>> + */
>>>>>>>> + if (!new_prog_set) {
>>>>>>>> + /*
>>>>>>>> + * If there is no Landlock program set used by the current task,
>>>>>>>> + * then create a new one.
>>>>>>>> + */
>>>>>>>> + new_prog_set = new_landlock_prog_set();
>>>>>>>> + if (IS_ERR(new_prog_set))
>>>>>>>> + goto put_tmp_lists;
>>>>>>>> + } else if (refcount_read(¤t_prog_set->usage) > 1) {
>>>>>>>> + /*
>>>>>>>> + * If the current task is not the sole user of its Landlock
>>>>>>>> + * program set, then duplicate them.
>>>>>>>> + */
>>>>>>>> + new_prog_set = new_landlock_prog_set();
>>>>>>>> + if (IS_ERR(new_prog_set))
>>>>>>>> + goto put_tmp_lists;
>>>>>>>> + for (i = 0; i < ARRAY_SIZE(new_prog_set->programs); i++) {
>>>>>>>> + new_prog_set->programs[i] =
>>>>>>>> + READ_ONCE(current_prog_set->programs[i]);
>>>>>>>> + if (new_prog_set->programs[i])
>>>>>>>> + refcount_inc(&new_prog_set->programs[i]->usage);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + /*
>>>>>>>> + * Landlock program set from the current task will not be freed
>>>>>>>> + * here because the usage is strictly greater than 1. It is
>>>>>>>> + * only prevented to be freed by another task thanks to the
>>>>>>>> + * caller of landlock_prepend_prog() which should be locked if
>>>>>>>> + * needed.
>>>>>>>> + */
>>>>>>>> + landlock_put_prog_set(current_prog_set);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + /* prepend tmp_prog_set to new_prog_set */
>>>>>>>> + for (i = 0; i < ARRAY_SIZE(tmp_prog_set.programs); i++) {
>>>>>>>> + /* get the last new list */
>>>>>>>> + struct landlock_prog_list *last_list =
>>>>>>>> + tmp_prog_set.programs[i];
>>>>>>>> +
>>>>>>>> + if (last_list) {
>>>>>>>> + while (last_list->prev)
>>>>>>>> + last_list = last_list->prev;
>>>>>>>> + /* no need to increment usage (pointer replacement) */
>>>>>>>> + last_list->prev = new_prog_set->programs[i];
>>>>>>>> + new_prog_set->programs[i] = tmp_prog_set.programs[i];
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + new_prog_set->chain_last = tmp_prog_set.chain_last;
>>>>>>>> + return new_prog_set;
>>>>>>>> +
>>>>>>>> +put_tmp_lists:
>>>>>>>> + for (i = 0; i < ARRAY_SIZE(tmp_prog_set.programs); i++)
>>>>>>>> + put_landlock_prog_list(tmp_prog_set.programs[i]);
>>>>>>>> + return new_prog_set;
>>>>>>>> +}
>>>>>>>
>>>>>>> Nack on the chaining concept.
>>>>>>> Please do not reinvent the wheel.
>>>>>>> There is an existing mechanism for attaching/detaching/quering multiple
>>>>>>> programs attached to cgroup and tracing hooks that are also
>>>>>>> efficiently executed via BPF_PROG_RUN_ARRAY.
>>>>>>> Please use that instead.
>>>>>>>
>>>>>>
>>>>>> I don't see how that would help. Suppose you add a filter, then
>>>>>> fork(), and then the child adds another filter. Do you want to
>>>>>> duplicate the entire array? You certainly can't *modify* the array
>>>>>> because you'll affect processes that shouldn't be affected.
>>>>>>
>>>>>> In contrast, doing this through seccomp like the earlier patches
>>>>>> seemed just fine to me, and seccomp already had the right logic.
>>>>>
>>>>> it doesn't look to me that existing seccomp side of managing fork
>>>>> situation can be reused. Here there is an attempt to add 'chaining'
>>>>> concept which sort of an extension of existing seccomp style,
>>>>> but somehow heavily done on bpf side and contradicts cgroup/tracing.
>>>>>
>>>>
>>>> I don't see why the seccomp way can't be used. I agree with you that
>>>> the seccomp *style* shouldn't be used in bpf code like this, but I
>>>> think that Landlock programs can and should just live in the existing
>>>> seccomp chain. If the existing seccomp code needs some modification
>>>> to make this work, then so be it.
>>>
>>> +1
>>> if that was the case...
>>> but that's not my reading of the patch set.
>>
>> An earlier version of the patch set used the seccomp filter chain.
>> Mickaël, what exactly was wrong with that approach other than that the
>> seccomp() syscall was awkward for you to use? You could add a
>> seccomp_add_landlock_rule() syscall if you needed to.
>
> Nothing was wrong about about that, this part did not changed (see my
> next comment).
>
>>
>> As a side comment, why is this an LSM at all, let alone a non-stacking
>> LSM? It would make a lot more sense to me to make Landlock depend on
>> having LSMs configured in but to call the landlock hooks directly from
>> the security_xyz() hooks.
>
> See Casey's answer and his patch series: https://lwn.net/Articles/741963/
>
>>
>>>
>>>> In other words, the kernel already has two kinds of chaining:
>>>> seccomp's and bpf's. bpf's doesn't work right for this type of usage
>>>> across fork(), whereas seccomp's already handles that case correctly.
>>>> (In contrast, seccomp's is totally wrong for cgroup-attached filters.)
>>>> So IMO Landlock should use the seccomp core code and call into bpf
>>>> for the actual filtering.
>>>
>>> +1
>>> in cgroup we had to invent this new BPF_PROG_RUN_ARRAY mechanism,
>>> since cgroup hierarchy can be complicated with bpf progs attached
>>> at different levels with different override/multiprog properties,
>>> so walking link list and checking all flags at run-time would have
>>> been too slow. That's why we added compute_effective_progs().
>>
>> If we start adding override flags to Landlock, I think we're doing it
>> wrong. With cgroup bpf programs, the whole mess is set up by the
>> administrator. With seccomp, and with Landlock if done correctly, it
>> *won't* be set up by the administrator, so the chance that everyone
>> gets all the flags right is about zero. All attached filters should
>> run unconditionally.
>
>
> There is a misunderstanding about this chaining mechanism. This should
> not be confused with the list of seccomp filters nor the cgroup
> hierarchies. Landlock programs can be stacked the same way seccomp's
> filters can (cf. struct landlock_prog_set, the "chain_last" field is an
> optimization which is not used for this struct handling). This stackable
> property did not changed from the previous patch series. The chaining
> mechanism is for another use case, which does not make sense for seccomp
> filters nor other eBPF program types, at least for now, from what I can
> tell.
>
> You may want to get a look at my talk at FOSDEM
> (https://landlock.io/talks/2018-02-04_landlock-fosdem.pdf), especially
> slides 11 and 12.
>
> Let me explain my reasoning about this program chaining thing.
>
> To check if an action on a file is allowed, we first need to identify
> this file and match it to the security policy. In a previous
> (non-public) patch series, I tried to use one type of eBPF program to
> check every kind of access to a file. To be able to identify a file, I
> relied on an eBPF map, similar to the current inode map. This map store
> a set of references to file descriptors. I then created a function
> bpf_is_file_beneath() to check if the requested file was beneath a file
> in the map. This way, no chaining, only one eBPF program type to check
> an access to a file... but some issues then emerged. First, this design
> create a side-channel which help an attacker using such a program to
> infer some information not normally available, for example to get a hint
> on where a file descriptor (received from a UNIX socket) come from.
> Another issue is that this type of program would be called for each
> component of a path. Indeed, when the kernel check if an access to a
> file is allowed, it walk through all of the directories in its path
> (checking if the current process is allowed to execute them). That first
> attempt led me to rethink the way we could filter an access to a file
> *path*.
>
> To minimize the number of called to an eBPF program dedicated to
> validate an access to a file path, I decided to create three subtype of
> eBPF programs. The FS_WALK type is called when walking through every
> directory of a file path (except the last one if it is the target). We
> can then restrict this type of program to the minimum set of functions
> it is allowed to call and the minimum set of data available from its
> context. The first implicit chaining is for this type of program. To be
> able to evaluate a path while being called for all its components, this
> program need to store a state (to remember what was the parent directory
> of this path). There is no "previous" field in the subtype for this
> program because it is chained with itself, for each directories. This
> enable to create a FS_WALK program to evaluate a file hierarchy, thank
> to the inode map which can be used to check if a directory of this
> hierarchy is part of an allowed (or denied) list of directories. This
> design enables to express a file hierarchy in a programmatic way,
> without requiring an eBPF helper to do the job (unlike my first experiment).
>
> The explicit chaining is used to tied a path evaluation (with a FS_WALK
> program) to an access to the actual file being requested (the last
> component of a file path), with a FS_PICK program. It is only at this
> time that the kernel check for the requested action (e.g. read, write,
> chdir, append...). To be able to filter such access request we can have
> one call to the same program for every action and let this program check
> for which action it was called. However, this design does not allow the
> kernel to know if the current action is indeed handled by this program.
> Hence, it is not possible to implement a cache mechanism to only call
> this program if it knows how to handle this action.
>
> The approach I took for this FS_PICK type of program is to add to its
> subtype which action it can handle (with the "triggers" bitfield, seen
> as ORed actions). This way, the kernel knows if a call to a FS_PICK
> program is necessary. If the user wants to enforce a different security
> policy according to the action requested on a file, then it needs
> multiple FS_PICK programs. However, to reduce the number of such
> programs, this patch series allow a FS_PICK program to be chained with
> another, the same way a FS_WALK is chained with itself. This way, if the
> user want to check if the action is a for example an "open" and a "read"
> and not a "map" and a "read", then it can chain multiple FS_PICK
> programs with different triggers actions. The OR check performed by the
> kernel is not a limitation then, only a way to know if a call to an eBPF
> program is needed.
>
> The last type of program is FS_GET. This one is called when a process
> get a struct file or change its working directory. This is the only
> program type able (and allowed) to tag a file. This restriction is
> important to not being subject to resource exhaustion attacks (i.e.
> tagging every inode accessible to an attacker, which would allocate too
> much kernel memory).
>
> This design gives room for improvements to create a cache of eBPF
> context (input data, including maps if any), with the result of an eBPF
> program. This would help limit the number of call to an eBPF program the
> same way SELinux or other kernel components do to limit costly checks.
>
> The eBPF maps of progs are useful to call the same type of eBPF
> program. It does not fit with this use case because we may want multiple
> eBPF program according to the action requested on a kernel object (e.g.
> FS_GET). The other reason is because the eBPF program does not know what
> will be the next (type of) access check performed by the kernel.
>
> To say it another way, this chaining mechanism is a way to split a
> kernel object evaluation with multiple specialized programs, each of
> them being able to deal with data tied to their type. Using a monolithic
> eBPF program to check everything does not scale and does not fit with
> unprivileged use either.
>
> As a side note, the cookie value is only an ephemeral value to keep a
> state between multiple programs call. It can be used to create a state
> machine for an object evaluation.
>
> I don't see a way to do an efficient and programmatic path evaluation,
> with different access checks, with the current eBPF features. Please let
> me know if you know how to do it another way.
>
Andy, Alexei, Daniel, what do you think about this Landlock program
chaining and cookie?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* KMSAN: uninit-value in _decode_session6
From: syzbot @ 2018-04-08 7:15 UTC (permalink / raw)
To: davem, herbert, kuznet, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs, yoshfuji
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=2974b85346f85b586f4d
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=4871594698604544
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329060) (llvm/trunk 329054)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2974b85346f85b586f4d@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: KMSAN: uninit-value in _decode_session6+0x6d1/0x1290
net/ipv6/xfrm6_policy.c:151
CPU: 1 PID: 5714 Comm: blkid Not tainted 4.16.0+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
_decode_session6+0x6d1/0x1290 net/ipv6/xfrm6_policy.c:151
__xfrm_decode_session+0x140/0x1c0 net/xfrm/xfrm_policy.c:2368
xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
icmpv6_route_lookup net/ipv6/icmp.c:372 [inline]
icmp6_send+0x305f/0x3460 net/ipv6/icmp.c:551
icmpv6_send+0xe0/0x110 net/ipv6/ip6_icmp.c:43
ip6_link_failure+0x8f/0x580 net/ipv6/route.c:2034
dst_link_failure include/net/dst.h:426 [inline]
ndisc_error_report+0x101/0x1a0 net/ipv6/ndisc.c:695
neigh_invalidate+0x385/0x930 net/core/neighbour.c:883
neigh_timer_handler+0xd85/0x12d0 net/core/neighbour.c:969
call_timer_fn+0x26a/0x5a0 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0xda7/0x11c0 kernel/time/timer.c:1666
run_timer_softirq+0x43/0x70 kernel/time/timer.c:1692
__do_softirq+0x56d/0x93d kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x202/0x240 kernel/softirq.c:405
exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:541
smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1055
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:857
</IRQ>
RIP: 0010:kmsan_get_origin_address_noruntime+0x8f/0x260
include/linux/mmzone.h:1206
RSP: 0000:ffff880165b0fb40 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff12
RAX: ffff8801e5b0fcc8 RBX: 0000000000000000 RCX: ffff88021fff1580
RDX: 0000000000000580 RSI: 0000000000000000 RDI: ffff880165b0fcc8
RBP: ffff880165b0fb78 R08: 0000000001080020 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000068
R13: 00000000d3a0004b R14: ffff880165b0fcc8 R15: 0000000000000000
kmsan_set_origin_inline+0x6b/0x120 mm/kmsan/kmsan_instr.c:585
__msan_poison_alloca+0x15c/0x1d0 mm/kmsan/kmsan_instr.c:647
handle_mm_fault+0x1c8/0x7ba0 mm/memory.c:4114
__do_page_fault+0xec4/0x1a10 arch/x86/mm/fault.c:1423
do_page_fault+0xd3/0x260 arch/x86/mm/fault.c:1500
page_fault+0x45/0x50 arch/x86/entry/entry_64.S:1151
RIP: 0033:0x7f93ad8e4789
RSP: 002b:00007ffd11b3cf20 EFLAGS: 00010216
RAX: 00007f93ad4742a0 RBX: 00007f93adaf79a8 RCX: 00000000000004a8
RDX: 00007f93ad6a9028 RSI: aaaaaaaaaaaaaaab RDI: 0000000000000000
RBP: 00007ffd11b3d000 R08: 0000000000000001 R09: 0000000000000010
R10: 00007f93ad343a30 R11: 0000000000000206 R12: 00007f93ad325000
R13: 00007f93ad343220 R14: 00007f93ad33d748 R15: 00007f93adaef740
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:526
__msan_memcpy+0x19f/0x1f0 mm/kmsan/kmsan_instr.c:470
skb_copy_bits+0x63a/0xdb0 net/core/skbuff.c:2046
__pskb_pull_tail+0x483/0x22e0 net/core/skbuff.c:1883
pskb_may_pull include/linux/skbuff.h:2112 [inline]
_decode_session6+0x79f/0x1290 net/ipv6/xfrm6_policy.c:152
__xfrm_decode_session+0x140/0x1c0 net/xfrm/xfrm_policy.c:2368
xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
icmpv6_route_lookup net/ipv6/icmp.c:372 [inline]
icmp6_send+0x305f/0x3460 net/ipv6/icmp.c:551
icmpv6_send+0xe0/0x110 net/ipv6/ip6_icmp.c:43
ip6_link_failure+0x8f/0x580 net/ipv6/route.c:2034
dst_link_failure include/net/dst.h:426 [inline]
ndisc_error_report+0x101/0x1a0 net/ipv6/ndisc.c:695
neigh_invalidate+0x385/0x930 net/core/neighbour.c:883
neigh_timer_handler+0xd85/0x12d0 net/core/neighbour.c:969
call_timer_fn+0x26a/0x5a0 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0xda7/0x11c0 kernel/time/timer.c:1666
run_timer_softirq+0x43/0x70 kernel/time/timer.c:1692
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:814
kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:868
__alloc_pages_nodemask+0xf5b/0x5dc0 mm/page_alloc.c:4283
alloc_pages_current+0x6b5/0x970 mm/mempolicy.c:2055
alloc_pages include/linux/gfp.h:494 [inline]
skb_page_frag_refill+0x3ba/0x5e0 net/core/sock.c:2208
sk_page_frag_refill+0xa4/0x340 net/core/sock.c:2228
__ip6_append_data+0x1a20/0x4bb0 net/ipv6/ip6_output.c:1503
ip6_append_data+0x40e/0x6b0 net/ipv6/ip6_output.c:1576
rawv6_sendmsg+0x2787/0x4cc0 net/ipv6/raw.c:928
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
sock_write_iter+0x3b9/0x470 net/socket.c:909
do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
do_iter_write+0x30d/0xd40 fs/read_write.c:932
vfs_writev fs/read_write.c:977 [inline]
do_writev+0x3c9/0x830 fs/read_write.c:1012
SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
SyS_writev+0x56/0x80 fs/read_write.c:1082
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
---
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
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 v2 net-next 06/10] mlxsw: core: Fix arg name of MLXSW_CORE_RES_VALID and MLXSW_CORE_RES_GET
From: Ido Schimmel @ 2018-04-08 6:47 UTC (permalink / raw)
To: Sasha Levin
Cc: Ido Schimmel, Jiri Pirko, netdev@vger.kernel.org,
davem@davemloft.net, petrm@mellanox.com, stable@vger.kernel.org
In-Reply-To: <DM5PR2101MB1032EFDD097F68891B44FFC5FBBB0@DM5PR2101MB1032.namprd21.prod.outlook.com>
On Thu, Apr 05, 2018 at 01:33:46AM +0000, Sasha Levin wrote:
> Please let us know if you'd like to have this patch included in a stable tree.
Patch isn't needed in a stable tree. Thanks!
^ permalink raw reply
* Re: [PATCH v2 net-next 01/10] mlxsw: spectrum_acl: Fix flex actions header ifndef define construct
From: Ido Schimmel @ 2018-04-08 6:46 UTC (permalink / raw)
To: Sasha Levin
Cc: Ido Schimmel, Jiri Pirko, netdev@vger.kernel.org,
davem@davemloft.net, petrm@mellanox.com, stable@vger.kernel.org
In-Reply-To: <DM5PR2101MB1032E3A9B4AF70459074D385FBBB0@DM5PR2101MB1032.namprd21.prod.outlook.com>
On Thu, Apr 05, 2018 at 01:33:48AM +0000, Sasha Levin wrote:
> Please let us know if you'd like to have this patch included in a stable tree.
Patch isn't needed in a stable tree. Thanks!
^ permalink raw reply
* Re: [PATCH net 0/8] net: fix uninit-values in networking stack
From: David Miller @ 2018-04-08 2:40 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180407204243.176626-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 7 Apr 2018 13:42:35 -0700
> It seems syzbot got new features enabled, and fired some interesting
> reports. Oh well.
Series applied, however in patch #7 the condition syzbot detects
cannot happen.
In all code paths that lead to __mkroute_output() with res->type
uninitialized, __mkroute_output() will reassign the local variable
'type' before reading it.
Furthermore, by doing a full structure initialization lots of
unrelated things will be initialized now as well.
We explicitly are only setting up the "inputs" of the fib_result
object before we call fib_lookup(). The prefixlen and other members
have no business being initialized there.
^ permalink raw reply
* business Proposal / Geschäftsvorschlag
From: Anders Karlsson @ 2018-04-07 11:44 UTC (permalink / raw)
To: Recipients
I have a business Proposal for you, contact me directly
This business has a cash involvement of $250,000,000.00
Anders Karlsson
Ich habe einen Geschäftsvorschlag für Sie, kontaktieren Sie mich direkt
Dieses Unternehmen hat eine Beteiligung von $ 250.000.000,00
- [] Anders Karlsson
^ permalink raw reply
* Re: KMSAN: uninit-value in tipc_node_get_mtu
From: syzbot @ 2018-04-08 0:26 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
In-Reply-To: <0000000000008e46680569461f8d@google.com>
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=b0975ce9355b347c1546
So far this crash happened 16 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5297557005664256
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=4600034989441024
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5107856890134528
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b0975ce9355b347c1546@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.
==================================================================
BUG: KMSAN: uninit-value in tipc_node_find net/tipc/node.c:236 [inline]
BUG: KMSAN: uninit-value in tipc_node_get_mtu+0x200/0x7a0
net/tipc/node.c:185
CPU: 1 PID: 3571 Comm: syzkaller770798 Not tainted 4.16.0+ #82
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
tipc_node_find net/tipc/node.c:236 [inline]
tipc_node_get_mtu+0x200/0x7a0 net/tipc/node.c:185
__tipc_sendmsg+0x1b32/0x41c0 net/tipc/socket.c:1364
tipc_sendmsg+0xeb/0x140 net/tipc/socket.c:1265
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fd49
RSP: 002b:00007ffd0061aba8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
RDX: 0000000000000000 RSI: 000000002095ffc8 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----dnode@__tipc_sendmsg
Variable was created at:
__tipc_sendmsg+0x20c/0x41c0 net/tipc/socket.c:1272
tipc_sendmsg+0xeb/0x140 net/tipc/socket.c:1265
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3571 Comm: syzkaller770798 Tainted: G B 4.16.0+
#82
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+0x185/0x1d0 lib/dump_stack.c:53
panic+0x39d/0x940 kernel/panic.c:183
kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
tipc_node_find net/tipc/node.c:236 [inline]
tipc_node_get_mtu+0x200/0x7a0 net/tipc/node.c:185
__tipc_sendmsg+0x1b32/0x41c0 net/tipc/socket.c:1364
tipc_sendmsg+0xeb/0x140 net/tipc/socket.c:1265
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fd49
RSP: 002b:00007ffd0061aba8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
RDX: 0000000000000000 RSI: 000000002095ffc8 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* [PATCH net] sctp: do not leak kernel memory to user space
From: Eric Dumazet @ 2018-04-08 0:15 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
syzbot produced a nice report [1]
Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
to user space, because sin_zero (padding field) was not properly cleared.
[1]
BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227
CPU: 1 PID: 3586 Comm: syzkaller481044 Not tainted 4.16.0+ #82
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
copy_to_user include/linux/uaccess.h:184 [inline]
move_addr_to_user+0x32e/0x530 net/socket.c:227
___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4401c9
RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9
RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0
R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----addr@___sys_recvmsg
Variable was created at:
___sys_recvmsg+0xd5/0x810 net/socket.c:2172
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
Bytes 8-15 of 16 are uninitialized
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G B 4.16.0+ #82
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+0x185/0x1d0 lib/dump_stack.c:53
panic+0x39d/0x940 kernel/panic.c:183
kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
copy_to_user include/linux/uaccess.h:184 [inline]
move_addr_to_user+0x32e/0x530 net/socket.c:227
___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/sctp/ipv6.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 0d873c58e5167a8855d62de14d88dc738bc70e48..f1fc48e9689c039135efcbebac7eb9f4ba952c9c 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -728,8 +728,10 @@ static int sctp_v6_addr_to_user(struct sctp_sock *sp, union sctp_addr *addr)
sctp_v6_map_v4(addr);
}
- if (addr->sa.sa_family == AF_INET)
+ if (addr->sa.sa_family == AF_INET) {
+ memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero));
return sizeof(struct sockaddr_in);
+ }
return sizeof(struct sockaddr_in6);
}
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 8/8] soreuseport: initialise timewait reuseport field
From: Eric Dumazet @ 2018-04-07 20:42 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180407204243.176626-1-edumazet@google.com>
syzbot reported an uninit-value in inet_csk_bind_conflict() [1]
It turns out we never propagated sk->sk_reuseport into timewait socket.
[1]
BUG: KMSAN: uninit-value in inet_csk_bind_conflict+0x5f9/0x990 net/ipv4/inet_connection_sock.c:151
CPU: 1 PID: 3589 Comm: syzkaller008242 Not tainted 4.16.0+ #82
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
inet_csk_bind_conflict+0x5f9/0x990 net/ipv4/inet_connection_sock.c:151
inet_csk_get_port+0x1d28/0x1e40 net/ipv4/inet_connection_sock.c:320
inet6_bind+0x121c/0x1820 net/ipv6/af_inet6.c:399
SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
SyS_bind+0x54/0x80 net/socket.c:1460
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4416e9
RSP: 002b:00007ffce6d15c88 EFLAGS: 00000217 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 0100000000000000 RCX: 00000000004416e9
RDX: 000000000000001c RSI: 0000000020402000 RDI: 0000000000000004
RBP: 0000000000000000 R08: 00000000e6d15e08 R09: 00000000e6d15e08
R10: 0000000000000004 R11: 0000000000000217 R12: 0000000000009478
R13: 00000000006cd448 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
tcp_time_wait+0xf17/0xf50 net/ipv4/tcp_minisocks.c:283
tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
sk_backlog_rcv include/net/sock.h:908 [inline]
__release_sock+0x2d6/0x680 net/core/sock.c:2271
release_sock+0x97/0x2a0 net/core/sock.c:2786
tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
sock_release net/socket.c:595 [inline]
sock_close+0xe0/0x300 net/socket.c:1149
__fput+0x49e/0xa10 fs/file_table.c:209
____fput+0x37/0x40 fs/file_table.c:243
task_work_run+0x243/0x2c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x10e1/0x38d0 kernel/exit.c:867
do_group_exit+0x1a0/0x360 kernel/exit.c:970
SYSC_exit_group+0x21/0x30 kernel/exit.c:981
SyS_exit_group+0x25/0x30 kernel/exit.c:979
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
inet_twsk_alloc+0xaef/0xc00 net/ipv4/inet_timewait_sock.c:182
tcp_time_wait+0xd9/0xf50 net/ipv4/tcp_minisocks.c:258
tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
sk_backlog_rcv include/net/sock.h:908 [inline]
__release_sock+0x2d6/0x680 net/core/sock.c:2271
release_sock+0x97/0x2a0 net/core/sock.c:2786
tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
sock_release net/socket.c:595 [inline]
sock_close+0xe0/0x300 net/socket.c:1149
__fput+0x49e/0xa10 fs/file_table.c:209
____fput+0x37/0x40 fs/file_table.c:243
task_work_run+0x243/0x2c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x10e1/0x38d0 kernel/exit.c:867
do_group_exit+0x1a0/0x360 kernel/exit.c:970
SYSC_exit_group+0x21/0x30 kernel/exit.c:981
SyS_exit_group+0x25/0x30 kernel/exit.c:979
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
inet_twsk_alloc+0x13b/0xc00 net/ipv4/inet_timewait_sock.c:163
tcp_time_wait+0xd9/0xf50 net/ipv4/tcp_minisocks.c:258
tcp_rcv_state_process+0xebe/0x6490 net/ipv4/tcp_input.c:6003
tcp_v6_do_rcv+0x11dd/0x1d90 net/ipv6/tcp_ipv6.c:1331
sk_backlog_rcv include/net/sock.h:908 [inline]
__release_sock+0x2d6/0x680 net/core/sock.c:2271
release_sock+0x97/0x2a0 net/core/sock.c:2786
tcp_close+0x277/0x18f0 net/ipv4/tcp.c:2269
inet_release+0x240/0x2a0 net/ipv4/af_inet.c:427
inet6_release+0xaf/0x100 net/ipv6/af_inet6.c:435
sock_release net/socket.c:595 [inline]
sock_close+0xe0/0x300 net/socket.c:1149
__fput+0x49e/0xa10 fs/file_table.c:209
____fput+0x37/0x40 fs/file_table.c:243
task_work_run+0x243/0x2c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x10e1/0x38d0 kernel/exit.c:867
do_group_exit+0x1a0/0x360 kernel/exit.c:970
SYSC_exit_group+0x21/0x30 kernel/exit.c:981
SyS_exit_group+0x25/0x30 kernel/exit.c:979
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes: da5e36308d9f ("soreuseport: TCP/IPv4 implementation")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
include/net/inet_timewait_sock.h | 1 +
net/ipv4/inet_timewait_sock.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
index 899495589a7ea2bf693cdda42f83cec160e861b5..c7be1ca8e562f82ee9b24122cc21f45172458e23 100644
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -43,6 +43,7 @@ struct inet_timewait_sock {
#define tw_family __tw_common.skc_family
#define tw_state __tw_common.skc_state
#define tw_reuse __tw_common.skc_reuse
+#define tw_reuseport __tw_common.skc_reuseport
#define tw_ipv6only __tw_common.skc_ipv6only
#define tw_bound_dev_if __tw_common.skc_bound_dev_if
#define tw_node __tw_common.skc_nulls_node
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index c3ea4906d237e17dd03553834dc9b6a9bb87a889..88c5069b5d20c74a63323a284f8346aa90efb865 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -178,6 +178,7 @@ struct inet_timewait_sock *inet_twsk_alloc(const struct sock *sk,
tw->tw_dport = inet->inet_dport;
tw->tw_family = sk->sk_family;
tw->tw_reuse = sk->sk_reuse;
+ tw->tw_reuseport = sk->sk_reuseport;
tw->tw_hash = sk->sk_hash;
tw->tw_ipv6only = 0;
tw->tw_transparent = inet->transparent;
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 7/8] ipv4: fix uninit-value in ip_route_output_key_hash_rcu()
From: Eric Dumazet @ 2018-04-07 20:42 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180407204243.176626-1-edumazet@google.com>
syzbot complained that res.type could be used while not initialized.
Using RTN_UNSPEC as initial value seems better than using garbage.
BUG: KMSAN: uninit-value in __mkroute_output net/ipv4/route.c:2200 [inline]
BUG: KMSAN: uninit-value in ip_route_output_key_hash_rcu+0x31f0/0x3940 net/ipv4/route.c:2493
CPU: 1 PID: 12207 Comm: syz-executor0 Not tainted 4.16.0+ #81
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
__mkroute_output net/ipv4/route.c:2200 [inline]
ip_route_output_key_hash_rcu+0x31f0/0x3940 net/ipv4/route.c:2493
ip_route_output_key_hash net/ipv4/route.c:2322 [inline]
__ip_route_output_key include/net/route.h:126 [inline]
ip_route_output_flow+0x1eb/0x3c0 net/ipv4/route.c:2577
raw_sendmsg+0x1861/0x3ed0 net/ipv4/raw.c:653
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
SYSC_sendto+0x6c3/0x7e0 net/socket.c:1747
SyS_sendto+0x8a/0xb0 net/socket.c:1715
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x455259
RSP: 002b:00007fdc0625dc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007fdc0625e6d4 RCX: 0000000000455259
RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000020000080 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000004f7 R14: 00000000006fa7c8 R15: 0000000000000000
Local variable description: ----res.i.i@ip_route_output_flow
Variable was created at:
ip_route_output_flow+0x75/0x3c0 net/ipv4/route.c:2576
raw_sendmsg+0x1861/0x3ed0 net/ipv4/raw.c:653
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/route.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8322e479f2997b8f0a97b7d6c87434e91471a941..59bc6ab1a4ebc6ce30cf4878de4747d8ea214632 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2297,13 +2297,14 @@ struct rtable *ip_route_output_key_hash(struct net *net, struct flowi4 *fl4,
const struct sk_buff *skb)
{
__u8 tos = RT_FL_TOS(fl4);
- struct fib_result res;
+ struct fib_result res = {
+ .type = RTN_UNSPEC,
+ .fi = NULL,
+ .table = NULL,
+ .tclassid = 0,
+ };
struct rtable *rth;
- res.tclassid = 0;
- res.fi = NULL;
- res.table = NULL;
-
fl4->flowi4_iif = LOOPBACK_IFINDEX;
fl4->flowi4_tos = tos & IPTOS_RT_MASK;
fl4->flowi4_scope = ((tos & RTO_ONLINK) ?
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 6/8] dccp: initialize ireq->ir_mark
From: Eric Dumazet @ 2018-04-07 20:42 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180407204243.176626-1-edumazet@google.com>
syzbot reported an uninit-value read of skb->mark in iptable_mangle_hook()
Thanks to the nice report, I tracked the problem to dccp not caring
of ireq->ir_mark for passive sessions.
BUG: KMSAN: uninit-value in ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:66 [inline]
BUG: KMSAN: uninit-value in iptable_mangle_hook+0x5e5/0x720 net/ipv4/netfilter/iptable_mangle.c:84
CPU: 0 PID: 5300 Comm: syz-executor3 Not tainted 4.16.0+ #81
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:66 [inline]
iptable_mangle_hook+0x5e5/0x720 net/ipv4/netfilter/iptable_mangle.c:84
nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
nf_hook_slow+0x158/0x3d0 net/netfilter/core.c:483
nf_hook include/linux/netfilter.h:243 [inline]
__ip_local_out net/ipv4/ip_output.c:113 [inline]
ip_local_out net/ipv4/ip_output.c:122 [inline]
ip_queue_xmit+0x1d21/0x21c0 net/ipv4/ip_output.c:504
dccp_transmit_skb+0x15eb/0x1900 net/dccp/output.c:142
dccp_xmit_packet+0x814/0x9e0 net/dccp/output.c:281
dccp_write_xmit+0x20f/0x480 net/dccp/output.c:363
dccp_sendmsg+0x12ca/0x12d0 net/dccp/proto.c:818
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x455259
RSP: 002b:00007f1a4473dc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f1a4473e6d4 RCX: 0000000000455259
RDX: 0000000000000000 RSI: 0000000020b76fc8 RDI: 0000000000000015
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000004f0 R14: 00000000006fa720 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
ip_queue_xmit+0x1e35/0x21c0 net/ipv4/ip_output.c:502
dccp_transmit_skb+0x15eb/0x1900 net/dccp/output.c:142
dccp_xmit_packet+0x814/0x9e0 net/dccp/output.c:281
dccp_write_xmit+0x20f/0x480 net/dccp/output.c:363
dccp_sendmsg+0x12ca/0x12d0 net/dccp/proto.c:818
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
inet_csk_clone_lock+0x503/0x580 net/ipv4/inet_connection_sock.c:797
dccp_create_openreq_child+0x7f/0x890 net/dccp/minisocks.c:92
dccp_v4_request_recv_sock+0x22c/0xe90 net/dccp/ipv4.c:408
dccp_v6_request_recv_sock+0x290/0x2000 net/dccp/ipv6.c:414
dccp_check_req+0x7b9/0x8f0 net/dccp/minisocks.c:197
dccp_v4_rcv+0x12e4/0x2630 net/dccp/ipv4.c:840
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
reqsk_alloc include/net/request_sock.h:88 [inline]
inet_reqsk_alloc+0xc4/0x7f0 net/ipv4/tcp_input.c:6145
dccp_v4_conn_request+0x5cc/0x1770 net/dccp/ipv4.c:600
dccp_v6_conn_request+0x299/0x1880 net/dccp/ipv6.c:317
dccp_rcv_state_process+0x2ea/0x2410 net/dccp/input.c:612
dccp_v4_do_rcv+0x229/0x340 net/dccp/ipv4.c:682
dccp_v6_do_rcv+0x16d/0x1220 net/dccp/ipv6.c:578
sk_backlog_rcv include/net/sock.h:908 [inline]
__sk_receive_skb+0x60e/0xf20 net/core/sock.c:513
dccp_v4_rcv+0x24d4/0x2630 net/dccp/ipv4.c:874
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/dccp/ipv4.c | 1 +
net/dccp/ipv6.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index e65fcb45c3f6c1edc70fc9898ebe6404175b102f..b08feb219b44b67eadf408a33649d8c7ec9db2d0 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -614,6 +614,7 @@ int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
ireq = inet_rsk(req);
sk_rcv_saddr_set(req_to_sk(req), ip_hdr(skb)->daddr);
sk_daddr_set(req_to_sk(req), ip_hdr(skb)->saddr);
+ ireq->ir_mark = inet_request_mark(sk, skb);
ireq->ireq_family = AF_INET;
ireq->ir_iif = sk->sk_bound_dev_if;
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 5df7857fc0f3aeefb2ed0324d97d13cb68551383..6344f1b18a6a1b30cd2f3c559987a2c9e9546f81 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -351,6 +351,7 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
ireq->ir_v6_rmt_addr = ipv6_hdr(skb)->saddr;
ireq->ir_v6_loc_addr = ipv6_hdr(skb)->daddr;
ireq->ireq_family = AF_INET6;
+ ireq->ir_mark = inet_request_mark(sk, skb);
if (ipv6_opt_accepted(sk, skb, IP6CB(skb)) ||
np->rxopt.bits.rxinfo || np->rxopt.bits.rxoinfo ||
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 5/8] net: fix uninit-value in __hw_addr_add_ex()
From: Eric Dumazet @ 2018-04-07 20:42 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180407204243.176626-1-edumazet@google.com>
syzbot complained :
BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
memcmp+0x119/0x180 lib/string.c:861
__hw_addr_add_ex net/core/dev_addr_lists.c:60 [inline]
__dev_mc_add+0x1c2/0x8e0 net/core/dev_addr_lists.c:670
dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
addrconf_join_solict net/ipv6/addrconf.c:2078 [inline]
addrconf_dad_begin net/ipv6/addrconf.c:3828 [inline]
addrconf_dad_work+0x427/0x2150 net/ipv6/addrconf.c:3954
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
kthread+0x539/0x720 kernel/kthread.c:239
Fixes: f001fde5eadd ("net: introduce a list of device addresses dev_addr_list (v6)")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/core/dev_addr_lists.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index c0548d268e1a2ffa381082324cd5497c1fd49ffb..e3e6a3e2ca22a6ee634894e897b089773c820a9c 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -57,8 +57,8 @@ static int __hw_addr_add_ex(struct netdev_hw_addr_list *list,
return -EINVAL;
list_for_each_entry(ha, &list->list, list) {
- if (!memcmp(ha->addr, addr, addr_len) &&
- ha->type == addr_type) {
+ if (ha->type == addr_type &&
+ !memcmp(ha->addr, addr, addr_len)) {
if (global) {
/* check if addr is already used as global */
if (ha->global_use)
--
2.17.0.484.g0c8726318c-goog
^ 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