Syzbot reports the following task hang [1]:
INFO: task syz-executor255:8499 blocked for more than 143 seconds.
Not tainted 5.14.0-rc7-syzkaller #0
Call Trace:
context_switch kernel/sched/core.c:4681 [inline]
__schedule+0x93a/0x26f0 kernel/sched/core.c:5938
schedule+0xd3/0x270 kernel/sched/core.c:6017
__lock_sock+0x13d/0x260 net/core/sock.c:2644
lock_sock_nested+0xf6/0x120 net/core/sock.c:3185
lock_sock include/net/sock.h:1612 [inline]
rfcomm_sk_state_change+0xb4/0x390 net/bluetooth/rfcomm/sock.c:73
__rfcomm_dlc_close+0x1b6/0x8a0 net/bluetooth/rfcomm/core.c:489
rfcomm_dlc_close+0x1ea/0x240 net/bluetooth/rfcomm/core.c:520
__rfcomm_sock_close+0xac/0x260 net/bluetooth/rfcomm/sock.c:220
rfcomm_sock_shutdown+0xe9/0x210 net/bluetooth/rfcomm/sock.c:931
rfcomm_sock_release+0x5f/0x140 net/bluetooth/rfcomm/sock.c:951
__sock_release+0xcd/0x280 net/socket.c:649
sock_close+0x18/0x20 net/socket.c:1314
__fput+0x288/0x920 fs/file_table.c:280
task_work_run+0xdd/0x1a0 kernel/task_work.c:164
exit_task_work include/linux/task_work.h:32 [inline]
do_exit+0xbd4/0x2a60 kernel/exit.c:825
do_group_exit+0x125/0x310 kernel/exit.c:922
get_signal+0x47f/0x2160 kernel/signal.c:2808
arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:865
handle_signal_work kernel/entry/common.c:148 [inline]
exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:209
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae
Showing all locks held in the system:
1 lock held by khungtaskd/1653:
#0: ffffffff8b97c280 (rcu_read_lock){....}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
1 lock held by krfcommd/4781:
#0: ffffffff8d306528 (rfcomm_mutex){+.+.}-{3:3}, at:
rfcomm_process_sessions net/bluetooth/rfcomm/core.c:1979 [inline]
#0: ffffffff8d306528 (rfcomm_mutex){+.+.}-{3:3}, at:
rfcomm_run+0x2ed/0x4a20 net/bluetooth/rfcomm/core.c:2086
2 locks held by in:imklog/8206:
#0: ffff8880182ce5f0 (&f->f_pos_lock){+.+.}-{3:3}, at:
__fdget_pos+0xe9/0x100 fs/file.c:974
#1: ffff8880b9c51a58 (&rq->__lock){-.-.}-{2:2}, at:
raw_spin_rq_lock_nested kernel/sched/core.c:460 [inline]
#1: ffff8880b9c51a58 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock
kernel/sched/sched.h:1307 [inline]
#1: ffff8880b9c51a58 (&rq->__lock){-.-.}-{2:2}, at: rq_lock
kernel/sched/sched.h:1610 [inline]
#1: ffff8880b9c51a58 (&rq->__lock){-.-.}-{2:2}, at:
__schedule+0x233/0x26f0 kernel/sched/core.c:5852
4 locks held by syz-executor255/8499:
#0: ffff888039a83690 (&sb->s_type->i_mutex_key#13){+.+.}-{3:3}, at:
inode_lock include/linux/fs.h:774 [inline]
#0: ffff888039a83690 (&sb->s_type->i_mutex_key#13){+.+.}-{3:3}, at:
__sock_release+0x86/0x280 net/socket.c:648
#1:
ffff88802fa31120 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0},
at: lock_sock include/net/sock.h:1612 [inline]
#1:
ffff88802fa31120 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0},
at: rfcomm_sock_shutdown+0x54/0x210 net/bluetooth/rfcomm/sock.c:928
#2: ffffffff8d306528 (rfcomm_mutex){+.+.}-{3:3}, at:
rfcomm_dlc_close+0x34/0x240 net/bluetooth/rfcomm/core.c:507
#3: ffff888141bd6d28 (&d->lock){+.+.}-{3:3}, at:
__rfcomm_dlc_close+0x162/0x8a0 net/bluetooth/rfcomm/core.c:487
==================================================================
The task hangs because of a deadlock that occurs when lock_sock() is
called in rfcomm_sk_state_change(). One such call stack is:
rfcomm_sock_shutdown():
lock_sock();
__rfcomm_sock_close():
rfcomm_dlc_close():
__rfcomm_dlc_close():
rfcomm_dlc_lock();
rfcomm_sk_state_change():
lock_sock();
lock_sock() has to be called when the sk state is changed because the
lock is not always held when rfcomm_sk_state_change() is
called. However, besides the recursive deadlock, there is also an
issue of a lock hierarchy inversion between rfcomm_dlc_lock() and
lock_sock() if the socket is locked in rfcomm_sk_state_change().
To avoid these issues, we can instead schedule the sk state change in
the global workqueue. This is already the implicit assumption about
how sk state changes happen. For example, in rfcomm_sock_shutdown(),
the call to __rfcomm_sock_close() is followed by
bt_sock_wait_state().
Additionally, the call to rfcomm_sock_kill() inside
rfcomm_sk_state_change() should be removed. The socket shouldn't be
killed here because only rfcomm_sock_release() calls sock_orphan(),
which it already follows up with a call to rfcomm_sock_kill().
Fixes: b7ce436a5d ("Bluetooth: switch to lock_sock in RFCOMM")
Link: https://syzkaller.appspot.com/bug?extid=7d51f807c81b190a127d [1]
Reported-by: syzbot+7d51f807c81b190a127d@syzkaller.appspotmail.com
Tested-by: syzbot+7d51f807c81b190a127d@syzkaller.appspotmail.com
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Cc: Hillf Danton <hdanton@sina.com>
Read codec capabilities only if HCI_READ_LOCAL_CODEC_CAPABILITIES
command is supported. If capablities are not supported, then
cache codec data without caps.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For: https://bugs.archlinux.org/task/73454
Intel Read Verision(TLV) data is parsed into a local structure variable
and it contains a field for bd address. Bd address is returned only in
bootloader mode and hence bd address in TLV structure needs to be validated
only if controller is present in boot loader mode.
Signed-off-by: Kiran K <kiran.k@intel.com>
Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit 893505319c74cf3faa45a5ed9d5338ff03b66949)
Recent attempts at using the GLIBC workaround resulted in hitting
a bug due to changed in GLIBC 2.35. Use the updated prebuilt which
addresses this issue.
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
Tracked by Arch Linux maintainers at https://bugs.archlinux.org/task/69563
Whenever using binaries compiled with never GLIBC versions on older
hosts we have obscure issues with faccesat2 and other permission
related calls. We workaround this issue by bootstrapping from a
statically compiled pacman and using specially patched GLIBC binary
packages to allow the container environment to function as normal.
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
A significant amount of time is spent in cloning the entire repository
before a build commences. Lets only perform a shallow clone to save
bandwith and time.
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
This is a simple compile test that will run after a push to branch head
occurs. We append the necessary Kconfig parameters as well.
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
On T2 Macs, the secure boot is handled by the T2 Chip. If enabled, only
macOS and Windows are allowed to boot on these machines. Thus we need to
disable secure boot for Linux. If we boot into Linux after disabling
secure boot, if CONFIG_LOAD_UEFI_KEYS is enabled, EFI Runtime services
fail to start, with the following logs in dmesg
Call Trace:
<TASK>
page_fault_oops+0x4f/0x2c0
? search_bpf_extables+0x6b/0x80
? search_module_extables+0x50/0x80
? search_exception_tables+0x5b/0x60
kernelmode_fixup_or_oops+0x9e/0x110
__bad_area_nosemaphore+0x155/0x190
bad_area_nosemaphore+0x16/0x20
do_kern_addr_fault+0x8c/0xa0
exc_page_fault+0xd8/0x180
asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
? __efi_call+0x28/0x30
? switch_mm+0x20/0x30
? efi_call_rts+0x19a/0x8e0
? process_one_work+0x222/0x3f0
? worker_thread+0x4a/0x3d0
? kthread+0x17a/0x1a0
? process_one_work+0x3f0/0x3f0
? set_kthread_struct+0x40/0x40
? ret_from_fork+0x22/0x30
</TASK>
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000
This patch prevents querying of these UEFI variables, since these Macs
seem to use a non-standard EFI hardware
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg <gargaditya08@live.com>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
The calibration blob for a chip is normally stored in SROM and loaded
internally by the firmware. However, Apple ARM64 platforms instead store
it as part of platform configuration data, and provide it via the Apple
Device Tree. We forward this into the Linux DT in the bootloader.
Add support for taking this blob from the DT and loading it into the
dongle. The loading mechanism is the same as used for the CLM and TxCap
blobs.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
These blobs are named .txcap_blob, and exist alongside the existing
.clm_blob files. Use the existing firmware machinery to provide them to
the core.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
The TxCap blobs are additional data blobs used on Apple devices, and
are uploaded analogously to CLM blobs. Add core support for doing this.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
Make all the iovar name arguments const char * instead of just char *.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that
the CLM blob is released in the device remove path.
Fixes: 82f93cf46d ("brcmfmac: get chip's default RAM info during PCIe setup")
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
This allows us to get console messages if the firmware crashed during
early init, or if an operation failed and we're about to shut down.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
The alignment check was wrong (e.g. & 4 instead of & 3), and the logic
was also inefficient if the length was not a multiple of 4, since it
would needlessly fall back to copying the entire buffer bytewise.
We already have a perfectly good memcpy_toio function, so just call that
instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers
was already using it anyway.
Fixes: 9e37f045d5 ("brcmfmac: Adding PCIe bus layer support.")
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.
OpenBSD has been doing it like this from the beginning, so this should
work on all chips.
Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
Add support for the new PMKID_V3 API, which allows performing PMKID
mutations individually, instead of requiring the driver to keep track of
the full list. This new API is required by at least BCM4387.
Note that PMKID_V2 is not implemented yet.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
The "wlc_ver" iovar returns information on the WLC and EPI versions.
This can be used to determine whether the PMKID_V2 and _V3 features are
supported.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net>
Jan Alexander Steffens (heftig)
Tzung-Bi Shih
Deren Wu
Desmond Cheong Zhi Xi
Kiran K
Jan Alexander Steffens (heftig)
Aun-Ali Zaidi
Aditya Garg
Hector Martin