Re: skb_over_panic using UDP and 6lowpan / fakelb

(Cc'ing netdev and maintainers) On Mon, Mar 27, 2017 at 2:16 AM, David Palma wrote: > > Hi, > > Sending a simple UDP packet (39 bytes long), over a 6lowpan interface > (using fakelb), creates a kernel panic (skb_over_panic). > > Steps to reproduce, and more details, can be found in: >

Re: net/sched: GPF in qdisc_hash_add

On Thu, Mar 23, 2017 at 12:10 PM, Eric Dumazet <eduma...@google.com> wrote: > On Thu, Mar 23, 2017 at 12:06 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> >> On Thu, Mar 23, 2017 at 8:00 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >> > On Thu, Ma

Re: net/sched: GPF in qdisc_hash_add

On Thu, Mar 23, 2017 at 12:10 PM, Eric Dumazet wrote: > On Thu, Mar 23, 2017 at 12:06 PM, Dmitry Vyukov wrote: >> >> On Thu, Mar 23, 2017 at 8:00 PM, Cong Wang wrote: >> > On Thu, Mar 23, 2017 at 9:06 AM, Dmitry Vyukov wrote: >> >> kasan: CONFIG_KASAN_I

Re: net/sched: GPF in qdisc_hash_add

On Thu, Mar 23, 2017 at 9:06 AM, Dmitry Vyukov wrote: > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked

Re: net/sched: GPF in qdisc_hash_add

On Thu, Mar 23, 2017 at 9:06 AM, Dmitry Vyukov wrote: > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 2 PID:

Re: net/kcm: double free of kcm inode

On Thu, Mar 23, 2017 at 5:09 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer. Note the > preceding kmem_cache_alloc injected failure, it's most likely the root > cause. > > FAULT_INJECTION: forcing a failure. > name failslab,

Re: net/kcm: double free of kcm inode

On Thu, Mar 23, 2017 at 5:09 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer. Note the > preceding kmem_cache_alloc injected failure, it's most likely the root > cause. > > FAULT_INJECTION: forcing a failure. > name failslab, interval 1,

Re: net/sctp: recursive locking in sctp_do_peeloff

On Wed, Mar 15, 2017 at 5:52 AM, Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> wrote: > On Tue, Mar 14, 2017 at 09:52:15PM -0700, Cong Wang wrote: >> Instead of checking for the status of the sock, I believe the following >> one-line fix should do the trick too.

Re: net/sctp: recursive locking in sctp_do_peeloff

On Wed, Mar 15, 2017 at 5:52 AM, Marcelo Ricardo Leitner wrote: > On Tue, Mar 14, 2017 at 09:52:15PM -0700, Cong Wang wrote: >> Instead of checking for the status of the sock, I believe the following >> one-line fix should do the trick too. Can you give it a try? >> >

Re: net/sctp: recursive locking in sctp_do_peeloff

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov wrote: > On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner > wrote: >> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following

Re: net/sctp: recursive locking in sctp_do_peeloff

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov wrote: > On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner > wrote: >> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following recursive locking report while running >>> syzkaller fuzzer on

Re: net: deadlock between ip_expire/sch_direct_xmit

On Tue, Mar 14, 2017 at 7:56 AM, Eric Dumazet wrote: > On Tue, Mar 14, 2017 at 7:46 AM, Dmitry Vyukov wrote: > >> I am confused. Lockdep has observed both of these stacks: >> >>CPU0CPU1 >> >>

Re: net: deadlock between ip_expire/sch_direct_xmit

On Tue, Mar 14, 2017 at 7:56 AM, Eric Dumazet wrote: > On Tue, Mar 14, 2017 at 7:46 AM, Dmitry Vyukov wrote: > >> I am confused. Lockdep has observed both of these stacks: >> >>CPU0CPU1 >> >> lock(&(>lock)->rlock); >>

Re: net: BUG in unix_notinflight

On Tue, Mar 7, 2017 at 2:23 PM, Nikolay Borisov wrote: > >>> >>> >>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9 >>> >>> [ cut here ] >>> kernel BUG at net/unix/garbage.c:149! >>> invalid opcode: [#1] SMP KASAN >>>

Re: net: BUG in unix_notinflight

On Tue, Mar 7, 2017 at 2:23 PM, Nikolay Borisov wrote: > >>> >>> >>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9 >>> >>> [ cut here ] >>> kernel BUG at net/unix/garbage.c:149! >>> invalid opcode: [#1] SMP KASAN >>> Dumping ftrace buffer: >>>

Re: net: BUG in unix_notinflight

On Tue, Mar 7, 2017 at 12:37 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Mar 6, 2017 at 11:34 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >> The problem here is there is no lock protecting concurrent unix_detach_fds() >> even though unix_notinflight() i

Re: net: BUG in unix_notinflight

On Tue, Mar 7, 2017 at 12:37 AM, Dmitry Vyukov wrote: > On Mon, Mar 6, 2017 at 11:34 PM, Cong Wang wrote: >> The problem here is there is no lock protecting concurrent unix_detach_fds() >> even though unix_notinflight() is already serialized, if we call >> unix_notinflight()

Re: net: BUG in unix_notinflight

On Mon, Mar 6, 2017 at 2:40 AM, Dmitry Vyukov wrote: > Now with a nice single-threaded C reproducer! Excellent... > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #define _GNU_SOURCE > #include > #include > #include > #include > #include >

Re: net: BUG in unix_notinflight

On Mon, Mar 6, 2017 at 2:40 AM, Dmitry Vyukov wrote: > Now with a nice single-threaded C reproducer! Excellent... > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > #include >

Re: netlink: GPF in netlink_unicast

On Mon, Mar 6, 2017 at 2:54 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following crash while running syzkaller fuzzer on > net-next/8d70eeb84ab277377c017af6a21d0a337025dede: > > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection

Re: netlink: GPF in netlink_unicast

On Mon, Mar 6, 2017 at 2:54 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following crash while running syzkaller fuzzer on > net-next/8d70eeb84ab277377c017af6a21d0a337025dede: > > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP

Re: net/ipv4: deadlock in ip_ra_control

On Fri, Mar 3, 2017 at 10:43 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>> On Wed, Mar 1,

Re: net/ipv4: deadlock in ip_ra_control

On Fri, Mar 3, 2017 at 10:43 AM, Dmitry Vyukov wrote: > On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov wrote: >> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote: >>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote: >>>> Hello, >>>> >>>>

Re: net/ipv6: null-ptr-deref in ip6mr_sk_done

On Sun, Mar 5, 2017 at 8:54 AM, Andrey Konovalov wrote: > Hi, > > I've got the following bug report while fuzzing the kernel with syzkaller. > Unfortunately it's not reproducible. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > kasan: GPF could be

Re: net/ipv6: null-ptr-deref in ip6mr_sk_done

On Sun, Mar 5, 2017 at 8:54 AM, Andrey Konovalov wrote: > Hi, > > I've got the following bug report while fuzzing the kernel with syzkaller. > Unfortunately it's not reproducible. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > kasan: GPF could be caused by NULL-ptr deref or

Re: net/kcm: use-after-free in kcm_wq

On Fri, Mar 3, 2017 at 2:11 AM, Dmitry Vyukov wrote: > Also like this one: > > == > BUG: KASAN: use-after-free in atomic_long_read > include/linux/compiler.h:254 [inline] at addr 8800538aba60 > BUG: KASAN:

Re: net/kcm: use-after-free in kcm_wq

On Fri, Mar 3, 2017 at 2:11 AM, Dmitry Vyukov wrote: > Also like this one: > > == > BUG: KASAN: use-after-free in atomic_long_read > include/linux/compiler.h:254 [inline] at addr 8800538aba60 > BUG: KASAN: use-after-free in

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet <eduma...@google.com> wrote: > On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > >> >> But I doubt skb_orphan() is the solution here, shouldn't we just >> update sk->sk_wmem_alloc with

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet wrote: > On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote: > >> >> But I doubt skb_orphan() is the solution here, shouldn't we just >> update sk->sk_wmem_alloc with skb->truesize changes? > > Is it worth it ? Ap

Re: [PATCH v4] net: don't call strlen() on the user buffer in packet_bind_spkt()

On Wed, Mar 1, 2017 at 3:57 AM, Alexander Potapenko wrote: > This happens because addr.sa_data copied from the userspace is not > zero-terminated, and copying it with strlcpy() in packet_bind_spkt() > results in calling strlen() on the kernel copy of that non-terminated >

Re: [PATCH v4] net: don't call strlen() on the user buffer in packet_bind_spkt()

On Wed, Mar 1, 2017 at 3:57 AM, Alexander Potapenko wrote: > This happens because addr.sa_data copied from the userspace is not > zero-terminated, and copying it with strlcpy() in packet_bind_spkt() > results in calling strlen() on the kernel copy of that non-terminated > buffer. Very similar to

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:54 PM, Eric Dumazet <eduma...@google.com> wrote: > On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>> >>> This one looks very similar to a previous one: >>> https://groups.google.com/forum/#!topic

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:54 PM, Eric Dumazet wrote: > On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote: >>> >>> This one looks very similar to a previous one: >>> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >>> >>> Both happen on

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:24 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >> Hello, >> >> I am seeing the following use-after-free report while running >

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:24 PM, Cong Wang wrote: > On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov wrote: >> Hello, >> >> I am seeing the following use-after-free report while running >> syzkaller fuzzer on >> linux-next/3e73502

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov wrote: > Hello, > > I am seeing the following use-after-free report while running > syzkaller fuzzer on > linux-next/3e7350242c6f3d41d28e03418bd781cc1b7bad5f: > > ==

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov wrote: > Hello, > > I am seeing the following use-after-free report while running > syzkaller fuzzer on > linux-next/3e7350242c6f3d41d28e03418bd781cc1b7bad5f: > > == > BUG: KASAN:

Re: net/ipv4: deadlock in ip_ra_control

On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following deadlock report while running syzkaller fuzzer > on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: > > == > [ INFO: possible

Re: net/ipv4: deadlock in ip_ra_control

On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following deadlock report while running syzkaller fuzzer > on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: > > == > [ INFO: possible circular locking

Re: net: GPF in rt6_nexthop_info

On Tue, Feb 28, 2017 at 5:10 AM, Eric Dumazet wrote: > On Tue, 2017-02-28 at 12:34 +0100, Dmitry Vyukov wrote: >> Hello, >> >> The following program triggers GPF in rt6_nexthop_info >> >> // autogenerated by syzkaller (http://github.com/google/syzkaller) >> #include >>

Re: net: GPF in rt6_nexthop_info

On Tue, Feb 28, 2017 at 5:10 AM, Eric Dumazet wrote: > On Tue, 2017-02-28 at 12:34 +0100, Dmitry Vyukov wrote: >> Hello, >> >> The following program triggers GPF in rt6_nexthop_info >> >> // autogenerated by syzkaller (http://github.com/google/syzkaller) >> #include >> #include >> #include >>

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 12:05 PM, Andrey Konovalov <andreyk...@google.com> wrote: > On Mon, Feb 27, 2017 at 8:59 PM, David Ahern <d...@cumulusnetworks.com> wrote: >> On 2/27/17 10:11 AM, Cong Wang wrote: >>> The attached patch fixes this crash, but I am not sure if

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 12:05 PM, Andrey Konovalov wrote: > On Mon, Feb 27, 2017 at 8:59 PM, David Ahern wrote: >> On 2/27/17 10:11 AM, Cong Wang wrote: >>> The attached patch fixes this crash, but I am not sure if it is the >>> best way to fix this bug yet... &g

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 7:28 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > A reproducer and .config are attached. > > kasan:

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 7:28 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > A reproducer and .config are attached. > > kasan: CONFIG_KASAN_INLINE enabled >

Re: net: possible deadlock in skb_queue_tail

On Mon, Feb 20, 2017 at 5:29 AM, Andrey Konovalov wrote: > other info that might help us debug this: > > Possible unsafe locking scenario: > >CPU0CPU1 > > lock(&(>lock)->rlock); >

Re: net: possible deadlock in skb_queue_tail

On Mon, Feb 20, 2017 at 5:29 AM, Andrey Konovalov wrote: > other info that might help us debug this: > > Possible unsafe locking scenario: > >CPU0CPU1 > > lock(&(>lock)->rlock); >

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C wrote: > > My card seems to use the e1000e driver which is buit-in.. > > Anyway here an objdump -x : > > http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt > Found disable_hardirq() but not

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C wrote: > > My card seems to use the e1000e driver which is buit-in.. > > Anyway here an objdump -x : > > http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt > Found disable_hardirq() but not disable_irq(). Are you sure the

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C <nix.or@gmail.com> wrote: > > > On 17.02.2017 23:38, Cong Wang wrote: >> >> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C <nix.or@gmail.com> wrote: >>> >>> Hi all, >>> >>&g

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C wrote: > > > On 17.02.2017 23:38, Cong Wang wrote: >> >> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: >>> >>> Hi all, >>> >>> while poking at a different issue I found the following on my lo

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: > Hi all, > > while poking at a different issue I found the following on my logs : > > [85362.132770] BUG: sleeping function called from invalid context at > kernel/irq/manage.c:110 > [85362.132771] in_atomic(): 1,

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: > Hi all, > > while poking at a different issue I found the following on my logs : > > [85362.132770] BUG: sleeping function called from invalid context at > kernel/irq/manage.c:110 > [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153,

Re: net: use-after-free in tw_timer_handler

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>>>>> >>>>>> This code was changed a long time ago : >>>>>> >>>

Re: net: use-after-free in tw_timer_handler

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov wrote: > On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang wrote: >>>>>> >>>>>> This code was changed a long time ago : >>>>>> >>>>>> https://git.kernel.org/cgit/linux/kernel

Re: net: use-after-free in tw_timer_handler

On Wed, Feb 8, 2017 at 9:36 AM, Dmitry Vyukov wrote: > On Tue, Jan 24, 2017 at 4:52 PM, Eric Dumazet wrote: >> On Tue, Jan 24, 2017 at 7:06 AM, Dmitry Vyukov wrote: This code was changed a long time ago :

Re: net: use-after-free in tw_timer_handler

On Wed, Feb 8, 2017 at 9:36 AM, Dmitry Vyukov wrote: > On Tue, Jan 24, 2017 at 4:52 PM, Eric Dumazet wrote: >> On Tue, Jan 24, 2017 at 7:06 AM, Dmitry Vyukov wrote: This code was changed a long time ago :

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. > > A reproducer and .config are attached. > Note, that it takes quite

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. > > A reproducer and .config are attached. > Note, that it takes quite some time to trigger the

Re: net/kcm: GPF in kcm_sendmsg

On Mon, Feb 13, 2017 at 7:14 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers GPF in kcm_sendmsg: > > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #define _GNU_SOURCE > #include > #include > #include > #include > #include >

Re: net/kcm: GPF in kcm_sendmsg

On Mon, Feb 13, 2017 at 7:14 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers GPF in kcm_sendmsg: > > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > > int

Re: net/packet: use-after-free in packet_rcv_fanout

On Fri, Feb 10, 2017 at 10:02 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2017-02-10 at 09:59 -0800, Eric Dumazet wrote: >> On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote: >> > On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet <eric.duma...@gmail.com> &

Re: net/packet: use-after-free in packet_rcv_fanout

On Fri, Feb 10, 2017 at 10:02 AM, Eric Dumazet wrote: > On Fri, 2017-02-10 at 09:59 -0800, Eric Dumazet wrote: >> On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote: >> > On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet >> > wrote: >> > > On Thu, 2017-0

Re: net/packet: use-after-free in packet_rcv_fanout

On Fri, Feb 10, 2017 at 9:59 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote: >> On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet

Re: net/packet: use-after-free in packet_rcv_fanout

On Fri, Feb 10, 2017 at 9:59 AM, Eric Dumazet wrote: > On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote: >> On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote: >> > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote: >> > >> >> More likely the bug is

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 7:33 PM, Sowmini Varadhan wrote: > On (02/09/17 19:19), Eric Dumazet wrote: >> >> More likely the bug is in fanout_add(), with a buggy sequence in error >> case, and not correct locking. >> >> kfree(po->rollover); >> po->rollover = NULL; >> >>

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 7:33 PM, Sowmini Varadhan wrote: > On (02/09/17 19:19), Eric Dumazet wrote: >> >> More likely the bug is in fanout_add(), with a buggy sequence in error >> case, and not correct locking. >> >> kfree(po->rollover); >> po->rollover = NULL; >> >> Two cpus entering fanout_add()

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote: > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote: > >> More likely the bug is in fanout_add(), with a buggy sequence in error >> case, and not correct locking. >> >> kfree(po->rollover); >> po->rollover = NULL; >>

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote: > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote: > >> More likely the bug is in fanout_add(), with a buggy sequence in error >> case, and not correct locking. >> >> kfree(po->rollover); >> po->rollover = NULL; >> >> Two cpus entering

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Feb 7, 2017 at 6:20 AM, Mateusz Guzik wrote: > > Yes, but unix_release_sock is expected to leave the file behind. > Note I'm not claiming there is a leak, but that racing threads will be > able to trigger a condition where you create a file and fail to bind it. > Which

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Feb 7, 2017 at 6:20 AM, Mateusz Guzik wrote: > > Yes, but unix_release_sock is expected to leave the file behind. > Note I'm not claiming there is a leak, but that racing threads will be > able to trigger a condition where you create a file and fail to bind it. > Which is expected,

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 5:14 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following use-after-free report in packet_rcv_fanout > while running syzkaller fuzzer on linux-next > e3e6c5f3544c5d05c6b3b309a34f4f2c3537e993. So far it happened once and > is not reproducible, but

Re: net/packet: use-after-free in packet_rcv_fanout

On Thu, Feb 9, 2017 at 5:14 AM, Dmitry Vyukov wrote: > Hello, > > I've got the following use-after-free report in packet_rcv_fanout > while running syzkaller fuzzer on linux-next > e3e6c5f3544c5d05c6b3b309a34f4f2c3537e993. So far it happened once and > is not reproducible, but maybe the stacks

[PATCH resend] 9p: fix a potential acl leak

.@suse.cz> Reviewed-by: Greg Kurz <gr...@kaod.org> Cc: Eric Van Hensbergen <eri...@gmail.com> Cc: Ron Minnich <rminn...@sandia.gov> Cc: Latchesar Ionkov <lu...@ionkov.net> Cc: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.co

[PATCH resend] 9p: fix a potential acl leak

Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Cc: Andrew Morton Signed-off-by: Cong Wang --- fs/9p/acl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/9p/acl.c b/fs/9p/acl.c index b3c2cc7..082d227 100644 --- a/fs/9p/acl.c +++ b/fs/9p/acl.c @@ -277,6 +277,7 @@ static int

Re: net/ipv6: double free in ipip6_dev_free

On Wed, Feb 8, 2017 at 5:56 AM, Dmitry Vyukov wrote: > First dev->tstats was freed here: > > 1376 static int ipip6_tunnel_init(struct net_device *dev) > 1377 { > 1378 struct ip_tunnel *tunnel = netdev_priv(dev); > 1379 int err; > 1380 > 1381 tunnel->dev

Re: net/ipv6: double free in ipip6_dev_free

On Wed, Feb 8, 2017 at 5:56 AM, Dmitry Vyukov wrote: > First dev->tstats was freed here: > > 1376 static int ipip6_tunnel_init(struct net_device *dev) > 1377 { > 1378 struct ip_tunnel *tunnel = netdev_priv(dev); > 1379 int err; > 1380 > 1381 tunnel->dev = dev; > 1382

Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()

On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez wrote: > When we igmpv3_add_delrec() we kzalloc the pmc, but when users > calligmpv3_del_delrec() we never free the pmc. This was caught > by the following kmemleak splat: > > unreferenced object 0x99666ff43b40 (size

Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()

On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez wrote: > When we igmpv3_add_delrec() we kzalloc the pmc, but when users > calligmpv3_del_delrec() we never free the pmc. This was caught > by the following kmemleak splat: > > unreferenced object 0x99666ff43b40 (size 192): > comm

Re: net/kcm: WARNING in kcm_write_msgs

On Mon, Feb 6, 2017 at 4:43 AM, Dmitry Vyukov wrote: > [resending as plain text] > > Hello, > > The following program triggers WARNING in kcm_write_msgs: > > WARNING: CPU: 3 PID: 2936 at net/kcm/kcmsock.c:627 > kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627 > CPU: 3 PID:

Re: net/kcm: WARNING in kcm_write_msgs

On Mon, Feb 6, 2017 at 4:43 AM, Dmitry Vyukov wrote: > [resending as plain text] > > Hello, > > The following program triggers WARNING in kcm_write_msgs: > > WARNING: CPU: 3 PID: 2936 at net/kcm/kcmsock.c:627 > kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627 > CPU: 3 PID: 2936 Comm: a.out Not

Re: net/icmp: null-ptr-deref in ping_v4_push_pending_frames

On Mon, Feb 6, 2017 at 11:39 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer. > > The null-ptr-deref is caused by sendto() on a socket(PF_INET, > SOCK_DGRAM, PROT_ICMP). > Note, that this requires the ability to

Re: net/icmp: null-ptr-deref in ping_v4_push_pending_frames

On Mon, Feb 6, 2017 at 11:39 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer. > > The null-ptr-deref is caused by sendto() on a socket(PF_INET, > SOCK_DGRAM, PROT_ICMP). > Note, that this requires the ability to create such sockets,

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik <mgu...@redhat.com> wrote: > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: >> Mind being more specific? > > Consider 2 threads which bind the same socket, but with different paths. > > Currently exactly one fil

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik wrote: > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: >> Mind being more specific? > > Consider 2 threads which bind the same socket, but with different paths. > > Currently exactly one file will get created,

Re: net: deadlock on genl_mutex

On Sun, Jan 29, 2017 at 2:11 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Dec 9, 2016 at 6:08 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>>> Chain exists of: >>>> Possible unsafe locking scenario: >&g

Re: net: deadlock on genl_mutex

On Sun, Jan 29, 2017 at 2:11 AM, Dmitry Vyukov wrote: > On Fri, Dec 9, 2016 at 6:08 AM, Cong Wang wrote: >>>> Chain exists of: >>>> Possible unsafe locking scenario: >>>> >>>>CPU0CPU1 >>>

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 3:59 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote: >> On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >> >> > Not sure if it is

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 3:59 PM, Eric Dumazet wrote: > On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote: >> On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang wrote: >> >> > Not sure if it is better. The difference is caught up in >> > net_enable_timestamp(), >&

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote: >> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet wrote: > On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote: >> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet wrote: >> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: >> > >> >> >> >> The conte

Re: net: suspicious RCU usage in nf_hook

On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > >> >> The context is process context (TX path before hitting qdisc), and >> BH is not disabled, so in_interrupt() doesn't catch it.

Re: net: suspicious RCU usage in nf_hook

On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet wrote: > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > >> >> The context is process context (TX path before hitting qdisc), and >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this >> makes me

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik <mgu...@redhat.com> wrote: > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik <mgu...@redhat.com> wrote: >> > Currently the file creation is potponed until uni

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik wrote: > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote: >> > Currently the file creation is potponed until unix_bind can no longer >> > fail otherwise

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > Oh well, I forgot to submit the official patch I t

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: >> > Oh well, I forgot to submit the official patch I think, Jan 9th. >> > >> > https://group

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > Oh well, I forgot to submit the official patch I think, Jan 9th. > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > Hmm, but why only fragments need skb_orphan()? It seems like any kfree_skb() inside

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > Oh well, I forgot to submit the official patch I think, Jan 9th. > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > Hmm, but why only fragments need skb_orphan()? It seems like any kfree_skb() inside a nf hook needs to have

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:22 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Fri, Jan 27, 2017 at 1:15 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> stack backtrace: >> CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192 >> Hardware name

<    2   3   4   5   6   7   8   9   10   11   >