lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 28 Jan 2018 11:24:01 -0800
From:   syzbot <syzbot+0f8d41363dab80c9a3e9@...kaller.appspotmail.com>
To:     coreteam@...filter.org, davem@...emloft.net, fw@...len.de,
        kadlec@...ckhole.kfki.hu, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        pablo@...filter.org, syzkaller-bugs@...glegroups.com
Subject: possible deadlock in xt_find_revision

Hello,

syzbot hit the following crash on net-next commit
6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +0000)
Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'

Unfortunately, I don't have any reproducer for this crash yet.
Raw console output is attached.
compiler: gcc (GCC) 7.1.1 20170620
.config is attached.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0f8d41363dab80c9a3e9@...kaller.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.15.0-rc9+ #212 Not tainted
------------------------------------------------------
syz-executor5/5416 is trying to acquire lock:
  (&xt[i].mutex){+.+.}, at: [<00000000f5db9e05>] xt_find_revision+0xc9/0x2b0  
net/netfilter/x_tables.c:367

but task is already holding lock:
dccp_invalid_packet: P.Data Offset(66) too large
  (sk_lock-AF_INET6){+.+.}, at: [<0000000049ab6b82>] lock_sock  
include/net/sock.h:1463 [inline]
  (sk_lock-AF_INET6){+.+.}, at: [<0000000049ab6b82>]  
ipv6_getsockopt+0x1c5/0x2e0 net/ipv6/ipv6_sockglue.c:1377

which lock already depends on the new lock.

dccp_invalid_packet: P.Data Offset(66) too large

the existing dependency chain (in reverse order) is:

-> #2 (sk_lock-AF_INET6){+.+.}:
        lock_sock_nested+0xc2/0x110 net/core/sock.c:2780
        lock_sock include/net/sock.h:1463 [inline]
        do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167
        ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922
        sctp_setsockopt+0x2b6/0x61d0 net/sctp/socket.c:4141
        sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
        SYSC_setsockopt net/socket.c:1849 [inline]
        SyS_setsockopt+0x189/0x360 net/socket.c:1828
        entry_SYSCALL_64_fastpath+0x29/0xa0

-> #1 (rtnl_mutex){+.+.}:
        __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
        rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
        unregister_netdevice_notifier+0x91/0x4e0 net/core/dev.c:1673
        clusterip_config_entry_put net/ipv4/netfilter/ipt_CLUSTERIP.c:114  
[inline]
        clusterip_tg_destroy+0x389/0x6e0  
net/ipv4/netfilter/ipt_CLUSTERIP.c:508
        cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
        __do_replace+0x79d/0xa50 net/ipv4/netfilter/ip_tables.c:1094
        do_replace net/ipv4/netfilter/ip_tables.c:1150 [inline]
        do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1680
        nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
        nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
        ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1260
        sctp_setsockopt+0x2b6/0x61d0 net/sctp/socket.c:4141
        sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
        SYSC_setsockopt net/socket.c:1849 [inline]
        SyS_setsockopt+0x189/0x360 net/socket.c:1828
        entry_SYSCALL_64_fastpath+0x29/0xa0

-> #0 (&xt[i].mutex){+.+.}:
        lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
        __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
        xt_find_revision+0xc9/0x2b0 net/netfilter/x_tables.c:367
        do_ip6t_get_ctl+0x963/0xaf0 net/ipv6/netfilter/ip6_tables.c:1742
        nf_sockopt net/netfilter/nf_sockopt.c:104 [inline]
        nf_getsockopt+0x6a/0xc0 net/netfilter/nf_sockopt.c:122
        ipv6_getsockopt+0x1df/0x2e0 net/ipv6/ipv6_sockglue.c:1378
        tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3326
        sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2937
        SYSC_getsockopt net/socket.c:1880 [inline]
        SyS_getsockopt+0x178/0x340 net/socket.c:1862
        entry_SYSCALL_64_fastpath+0x29/0xa0

other info that might help us debug this:

Chain exists of:
   &xt[i].mutex --> rtnl_mutex --> sk_lock-AF_INET6

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(sk_lock-AF_INET6);
                                lock(rtnl_mutex);
                                lock(sk_lock-AF_INET6);
   lock(&xt[i].mutex);

  *** DEADLOCK ***

1 lock held by syz-executor5/5416:
  #0:  (sk_lock-AF_INET6){+.+.}, at: [<0000000049ab6b82>] lock_sock  
include/net/sock.h:1463 [inline]
  #0:  (sk_lock-AF_INET6){+.+.}, at: [<0000000049ab6b82>]  
ipv6_getsockopt+0x1c5/0x2e0 net/ipv6/ipv6_sockglue.c:1377

stack backtrace:
CPU: 1 PID: 5416 Comm: syz-executor5 Not tainted 4.15.0-rc9+ #212
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/0x257 lib/dump_stack.c:53
  print_circular_bug.isra.37+0x2cd/0x2dc kernel/locking/lockdep.c:1218
  check_prev_add kernel/locking/lockdep.c:1858 [inline]
  check_prevs_add kernel/locking/lockdep.c:1971 [inline]
  validate_chain kernel/locking/lockdep.c:2412 [inline]
  __lock_acquire+0x30a8/0x3e00 kernel/locking/lockdep.c:3426
  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
  __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
  xt_find_revision+0xc9/0x2b0 net/netfilter/x_tables.c:367
  do_ip6t_get_ctl+0x963/0xaf0 net/ipv6/netfilter/ip6_tables.c:1742
  nf_sockopt net/netfilter/nf_sockopt.c:104 [inline]
  nf_getsockopt+0x6a/0xc0 net/netfilter/nf_sockopt.c:122
  ipv6_getsockopt+0x1df/0x2e0 net/ipv6/ipv6_sockglue.c:1378
  tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3326
  sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2937
  SYSC_getsockopt net/socket.c:1880 [inline]
  SyS_getsockopt+0x178/0x340 net/socket.c:1862
  entry_SYSCALL_64_fastpath+0x29/0xa0
RIP: 0033:0x453299
RSP: 002b:00007f4ed20bec58 EFLAGS: 00000212 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000453299
RDX: 0000000000000045 RSI: 0000000000000029 RDI: 0000000000000013
RBP: 00000000000005ca R08: 0000000020000000 R09: 0000000000000000
R10: 0000000020ab2fe2 R11: 0000000000000212 R12: 00000000006f7b90
R13: 00000000ffffffff R14: 00007f4ed20bf6d4 R15: 0000000000000000
netlink: 'syz-executor7': attribute type 21 has an invalid length.
netlink: 'syz-executor7': attribute type 21 has an invalid length.


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@...glegroups.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.

View attachment "raw.log.txt" of type "text/plain" (861599 bytes)

View attachment "config.txt" of type "text/plain" (136464 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ