linux-kernel - BUG in iscisd with 5.8-rc kernels

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>] [day] [month] [year] [list]

Message-ID: <CAB9dFds+EdaTor7EfmrHCNPVQTZ8BjX91a+jz0qP1uZAAcgaOw@mail.gmail.com>
Date:   Tue, 28 Jul 2020 16:11:51 -0300
From:   Marc Dionne <marc.c.dionne@...il.com>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     Daniel Borkmann <daniel@...earbox.net>
Subject: BUG in iscisd with 5.8-rc kernels

Since some point in the current 5.8 cycle, iscsid sometimes crashes
and fails to come up after a reboot.

Here is a sample BUG:

 kernel: BUG: scheduling while atomic: iscsid/763/0x00000200

 kernel: Call Trace:
 kernel:  dump_stack+0x6b/0x88
 kernel:  __schedule_bug.cold+0x4c/0x58
 kernel:  __schedule+0x646/0x800
 kernel:  schedule+0x4a/0xb0
 kernel:  __lock_sock+0x69/0x90
 kernel:  ? finish_wait+0x80/0x80
 kernel:  lock_sock_nested+0x4f/0x60
 kernel:  inet_getname+0x98/0xd0
 kernel:  iscsi_sw_tcp_conn_get_param+0x9b/0x110 [iscsi_tcp]
 kernel:  show_conn_ep_param_ISCSI_PARAM_CONN_ADDRESS+0x6d/0x90
[scsi_transport_iscsi]
 kernel:  dev_attr_show+0x16/0x40
 kernel:  sysfs_kf_seq_show+0x98/0xf0
 kernel:  seq_read+0xa8/0x420
 kernel:  vfs_read+0x9d/0x180
 kernel:  ksys_read+0x4f/0xc0
 kernel:  do_syscall_64+0x47/0x80
 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Not areas I'm familiar with, but looking at
iscsi_sw_tcp_conn_get_param, it uses this pattern:

    spin_lock_bh(&conn->session->frwd_lock)
    kernel_getsockname()/kernel_getpeername()
    spin_unlock_bh(&conn->session->frwd_lock)

.. and inet_getname since 1b66d253610c7 ("bpf: Add get{peer, sock}name
attach types for sock_addr") has a new BPF_CGROUP_RUN_SA_PROG_LOCK()
that will try to lock_sock the socket, while a spinlock is held.  I
suspect that when this needs to sleep, it triggers the BUG.

I cc'ed the author of that commit, not sure if any other lists would
be useful to cc.

Marc