| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix integer overflow in verify_tags() bounds check
verify_tags() validates the tagset table unpacked from a policy blob.
For each set it reads a count and checks that advancing the index by
that count stays inside sets.table[]:
u32 cnt = tags->sets.table[i];
if (i+cnt >= tags->sets.size) {
i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32.
sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so
every entry is a raw unbounded 32-bit word taken from the policy blob,
and verify_tags() is the function that is supposed to validate it. A
count close to U32_MAX makes the sum wrap to a small value, the guard
passes, and the inner loop then walks sets.table[++i] past the end of
the kcalloc(size, sizeof(u32)) allocation.
Note that sets.size is bounded by 65535, because unpack_tagsets() reads
it with aa_unpack_array() as a u16, so the wrap cannot be reached by
growing the table; it is reached purely through the attacker-supplied
count.
With sets.size = 2 and sets.table = { 0, 0xffffffff }:
i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run
i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is
false, so the guard is bypassed and the inner loop reads
sets.table[2] -- one element past a two element allocation
The walk continues until an out-of-bounds value happens to be >=
hdrs.size or the access faults, so a crafted policy yields an
out-of-bounds read on the policy load path
(aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags ->
verify_tags). unpack_tags() runs before the perms and DFA tables are
unpacked, so no other table needs to be well formed to reach it.
Policy load is gated by aa_may_manage_policy(), which checks
CAP_MAC_ADMIN relative to the subject's own user namespace rather than
the init user namespace, so with the default
unprivileged_userns_apparmor_policy=1 the path is reachable from an
unprivileged task in a matched-level nested namespace, not only by a
globally privileged one.
Perform the addition in u64 so that it cannot wrap, restoring the
intended i + cnt < sets.size guarantee. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix storage null-ptr-deref after replacing prog
Syzkaller reported a storage null-ptr-deref issue after replacing prog.
This occurs in the following scenario:
1. prog A, an empty prog, is attached to a cgrp.
2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the
bpf_get_local_storage helper.
3. link_update is called to replace prog A with prog B.
The reason is that __cgroup_bpf_replace fails to alloc and assign the
required cgrp storage for the incoming replacement prog. Consequently,
the new prog inherits an uninit storage, leading to null-ptr-deref panic
when kick the new prog.
Fix this by rejecting a link update if new_prog's cgroup storage is
incompatible with link->prog. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MSFT: validate evt_prefix_len against the response length
read_supported_features() only checks that the response covers the fixed
part of struct msft_rp_read_supported_features, which is 11 bytes:
if (skb->len < sizeof(*rp)) {
bt_dev_err(hdev, "MSFT supported features length mismatch");
goto failed;
}
evt_prefix[] is a flexible array member and rp->evt_prefix_len is an
unvalidated u8 taken straight out of that response, so
msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len,
GFP_KERNEL);
copies up to 255 bytes from a reply that may have carried none of them.
What is copied is data the controller never sent, and it is then used to
match incoming vendor events in msft_vendor_evt().
This is not an out-of-bounds access. An skb data allocation always has
at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the
payload, which is more than the 255 byte maximum, so the read stays
inside the allocation and KASAN does not report it. It is still a read
of bytes the host was never given, with the length fully controlled by
the controller.
Reject a response that is too short for the prefix it declares.
Verified with an emulated controller over /dev/vhci on a KASAN kernel,
with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk
and btrtl do unconditionally. A reply of exactly 11 bytes declaring
evt_prefix_len = 255 reaches kmemdup and copies 255 bytes
("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since
the reply ends at the fixed part, all 255 come from past the end of the
response. No KASAN report is produced, as expected from the allocation
slack described above. With this patch the response is rejected with
"MSFT event prefix length mismatch" and msft->evt_prefix is left unset. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: free the HCI command when it is cancelled
mgmt_hci_cmd_sync() queues the pending command with a NULL destroy
callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled
entry is leaked, as _hci_cmd_sync_cancel_entry() does not release
entry->data when there is no destroy callback, and hci_cmd_sync_clear()
cancels every pending entry when the controller is unregistered. Nothing
else reclaims it either: mgmt_pending_new() does not put the command on
hdev->mgmt_pending.
The leak also pins the socket reference taken by mgmt_pending_new(), so
the mgmt socket is never released.
Free the command from a destroy callback. The now-empty done label is
replaced by a direct return. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
mesh_send_cancel() queues the pending command with a NULL destroy
callback, so it is only freed if send_cancel() runs. A cancelled entry is
leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when
there is no destroy callback, and hci_cmd_sync_clear() cancels every
pending entry when the controller is unregistered. Nothing else reclaims
it either: mgmt_pending_new() does not put the command on
hdev->mgmt_pending.
The leak also pins the socket reference taken by mgmt_pending_new(), so
the mgmt socket is never released.
Free the command from a destroy callback. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths
adv_timeout_expire() hands a kmalloc()ed instance byte to
hci_cmd_sync_queue() with a NULL destroy callback, and only
adv_timeout_expire_sync() frees it. That leaks on two paths:
- the return value is not checked, and hci_cmd_sync_queue() does not
take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM);
- a cancelled entry is not released, as _hci_cmd_sync_cancel_entry()
does not free entry->data when there is no destroy callback.
hci_cmd_sync_clear() cancels every pending entry when the controller
is unregistered.
Free the buffer from a destroy callback, and in the caller when the entry
could not be queued at all. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: airoha: add missed IRQ resource helpers
Without hooking .irq_request_resources, gpiolib cannot set
GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow
userspace or another driver to reconfigure an active IRQ pin as an output |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: flush active metadata block group at btree_writepages() start
btree_writepages() writes the btree inode's dirty metadata in ascending
logical address order. On a zoned filesystem only one metadata and one
system block group is active for writing at a time, and
check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the
active block group as writeback moves from one block group to the next.
If the active block group sits at a higher logical address than another
block group that also holds dirty metadata, the ascending walk reaches
the lower one first and, to write it, has to finish the active block
group and activate the lower one. It cannot finish a block group that
still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit)
writeback it deliberately refuses to wait for that IO under
fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot
issue the submission itself either, so it gives up:
btrfs_check_meta_write_pointer() returns -EAGAIN, which
btrfs_write_and_wait_transaction() treats as fatal and aborts the
transaction, forcing the filesystem read-only. This happens
intermittently under metadata-heavy relocation (e.g. fstests btrfs/187).
Flush the active metadata and system block groups at the start of
btree_writepages(), under the fs_info->zoned_meta_io_lock it already
holds, so they have no unsent IO left and the later pivot can finish
them and make forward progress. |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: qcom-cpucp: handle NULL data in send_data callback
mailbox_clear_channel() calls mbox_send_message() with NULL data to
notify the remote side that the RX channel has been cleared.
qcom_cpucp_mbox_send_data() blindly dereferenced the data pointer,
causing a NULL pointer dereference kernel panic when invoked from
this path under PREEMPT_RT.
Add an explicit NULL check and return early without writing to the
TX register, which is the correct behaviour for a channel-clear
notification. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args
On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc
args. However, the RV64 JIT currently does not perform sign-extension for
such kfunc args.
Before commit 7ce090afbf72 ("bpf: Infer zext_dst based on static register
liveness analysis"), state pruning could potentially omit zero-extension
of 32-bit subregisters, which inadvertently masked the above issue by making
the args appear as if they had been properly sign-extended. After that
commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4
selftest to fail.
Fix this by extending the existing sign-extension logic to handle signed
1-byte and 2-byte kfunc args as well. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: haptic: don't write an uninitialized value to unhandled usages
fill_effect_buf() initializes value only for the four haptic usages
handled by its switch, but writes it to field->value[] for every usage.
An unhandled usage can therefore receive either an uninitialized value
or one left over from the previous usage. hid_output_report() then
serializes that value into the effect's report buffer.
Skip unhandled usages instead. This also matches switch_mode(), which
only updates fields it recognizes.
Found with Clang's -Wconditional-uninitialized. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix use-after-free in snd_card_do_free()
A use-after-free was detected in snd_card_do_free() when a sound card
managed by devres is unbound while a user-space application still holds an
open file descriptor.
For managed cards, the memory is allocated using devres_alloc(), and its
release function is set to __snd_card_release(), which calls
snd_card_free(). When the device is unbound, the unbind thread calls
snd_card_free(), which drops a reference to the card's device. If the user
thread still has an open file descriptor, the reference count does not
reach zero, and the unbind thread blocks on wait_for_completion(&released).
When the user thread closes the file descriptor, it drops the final
reference, invoking the device release callback release_card_device(),
which calls snd_card_do_free(). snd_card_do_free() performs cleanup and
calls complete(card->release_completion). This wakes up the unbind thread,
which returns from snd_card_free() and __snd_card_release(). The devres
core then immediately frees the memory block containing the snd_card
structure.
Meanwhile, the user thread continues execution in snd_card_do_free() and
evaluates `if (!card->managed)`. It reads the `managed` boolean from the
snd_card structure that was just freed by the unbind thread, triggering a
KASAN use-after-free.
Fix this by caching the value of card->managed in a local variable before
calling complete(). This ensures that the card pointer is not dereferenced
after the unbind thread has been woken up and potentially freed the card.
BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604
[inline]
BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0
sound/core/init.c:153
Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
snd_card_do_free sound/core/init.c:604 [inline]
release_card_device+0x1ab/0x1b0 sound/core/init.c:153
device_release+0xc4/0x1f0 drivers/base/core.c:-1
kobject_cleanup lib/kobject.c:689 [inline]
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x222/0x550 lib/kobject.c:737
snd_card_file_remove+0x331/0x390 sound/core/init.c:1125
snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986
__fput+0x418/0xa50 fs/file_table.c:512
fput_close_sync+0x11f/0x240 fs/file_table.c:617
__do_sys_close fs/open.c:1511 [inline]
__se_sys_close fs/open.c:1496 [inline]
__x64_sys_close+0x7e/0x110 fs/open.c:1496
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix max_qid race between configfs and controller allocation
The function nvmet_subsys_attr_qid_max_store() can race against
nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified.
Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes:
ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1);
and at this exact point, a userspace process changes max_qid to 128,
nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It
attempts to delete active controllers to force a reconnect, but the
new controller won't be deleted because it hasn't been added to the
subsys->ctrls list yet.
nvmet_alloc_ctrl() then proceeds and adds the new controller to the
subsys->ctrls list. Later, when nvmet_install_queue() is called, it
will see max_qid set to 128, but the memory allocated for sqs is only
sized for 64 entries. This results in a KASAN out-of-bounds warning
and potential memory corruptions.
Fix this by protecting the queue allocations and list insertion in
nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because
nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem)
to modify the attribute, this safely prevents the configfs writer from
modifying max_qid during controller creation.
Copy the max_qid from the subsystem to the controller's structure
during the allocation; ctrl->max_qid never changes as long as the
controller remains in LIVE state, so this will prevent similar race
conditions. |
| In the Linux kernel, the following vulnerability has been resolved:
clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type
Samsung PWM timer might be used as a clock source on some legacy systems.
When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
sleeping lock (mutex-based), which must not be used in atomic context
such as hard interrupt handlers. Switch the samsung_pwm_lock to the
raw_spinlock, which remains a true non-sleeping spinlock even
under PREEMPT_RT. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: retry verity reads for not-uptodate Merkle folios
btrfs_read_merkle_tree_page() can find a folio in the mapping that is not
uptodate. After taking the folio lock, the current code treats that state
as a read error and returns -EIO.
That can make a previous transient read failure sticky. If the failed read
left a not-uptodate folio in the mapping, later callers find that folio and
fail instead of retrying the read.
Keep the existing page-cache insertion and locking order, but retry the
Merkle item read when a not-uptodate folio is found in the mapping. Also
unlock the folio when read_key_bytes() fails so that a later caller can
lock it and retry the read. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: check if root is readonly when setting posix acl
For a filesystem which has btrfs read-only property set to true, all
write operations including acl and xattr should be denied. However, acl
can still be set even if btrfs ro property is true.
This happens because no function on the set_acl code path checks the root
is readonly or not. It was checked in btrfs_setxattr_trans() but got
removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root
check in btrfs_setxattr_trans")
That commit didn't check if all the callers properly check the root's
read-only flag. A previous fix is commit b51111271b03 ("btrfs: check if
root is readonly while setting security xattr").
Always check if the root is read-only before performing the set acl
operation. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64/efi: Avoid voluntary preemption with efi_mm installed
Gus reports a bad kernel memory access when using software PAN
(CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime
services:
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 00000000f322ff30
Mem abort info:
ESR = 0x0000000096000004
FSC = 0x04: level 0 translation fault
Internal error: Oops: 0000000096000004 [#1] SMP
Workqueue: efi_rts_wq efi_call_rts
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : efi_call_rts+0xd8/0x288
Call trace:
efi_call_rts+0xd8/0x288 (P)
process_one_work+0x178/0x4f8
worker_thread+0x194/0x328
This is because the fpsimd context management code called from
__efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI
code with an incorrect value for TTBR0_EL1 thanks to the deferred mm
switching used by the software PAN implementation.
Since EFI runtime services cannot preempt voluntarily and because the
fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply
reorder the fpsimd switch so that it occurs before we change the
page-table. |
| In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix memory leak in error path of build_tree()
In the error path of build_tree(), node instances can remain in the local
linked list when the function returns.
Whenever an invalid value is detected in the self ID sequence, each
allocated node instance is either an entry in the linked list or an
entry in the ports array of its parent node. Therefore, the allocate
node instances can be safely released by traversing the linked list from
its head.
Release the remaining node instances with for_each_fw_node() before
returning to the caller. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate ipc response length before dereferencing its fields
ipc_validate_msg() computes the expected message size by reading length
fields out of the response buffer supplied by the userspace ksmbd daemon
(payload_sz, session_key_len, ngroups, ...). Those fields are read before
the buffer is verified to be large enough to contain the struct they belong
to, so a short response makes the read land past the end of the allocation.
handle_response() sizes entry->response purely from the netlink attribute
length (nla_len()) and only guards the leading handle read, so the daemon
can install a response as small as the kmalloc-8 object seen below. When
ipc_msg_send_request() then calls ipc_validate_msg() for a
KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads
resp->payload_sz at offset 8 of an 8-byte allocation:
[ 3697.841381] ==================================================================
[ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800
[ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682
[ 3697.849061]
[ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy)
[ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work
[ 3697.850592] Call Trace:
[ 3697.850794] <TASK>
[ 3697.850952] __dump_stack+0x21/0x60
[ 3697.851239] dump_stack_lvl+0xc2/0x100
[ 3697.851528] print_address_description+0x77/0x200
[ 3697.851816] ? ipc_msg_send_request+0x763/0x800
[ 3697.852024] print_report+0x58/0x70
[ 3697.852316] kasan_report+0x117/0x150
[ 3697.852585] ? down_write+0x146/0x1f0
[ 3697.852809] ? ipc_msg_send_request+0x763/0x800
[ 3697.853082] ipc_msg_send_request+0x763/0x800
[ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10
[ 3697.853604] ? kasan_unpoison+0x48/0x70
[ 3697.853936] ? __pfx___up_read+0x10/0x10
[ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520
[ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10
[ 3697.854757] ? kasan_unpoison+0x48/0x70
[ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0
[ 3697.855166] ? kasan_unpoison+0x48/0x70
[ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0
[ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10
[ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10
[ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140
[ 3697.856620] smb2_ioctl+0x1141/0x3420
[ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10
[ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0
[ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0
[ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10
[ 3697.858251] ? lock_release+0xf7/0x360
[ 3697.858466] ? process_scheduled_works+0x954/0x1600
[ 3697.858698] ? process_scheduled_works+0x954/0x1600
[ 3697.858905] process_scheduled_works+0xc22/0x1600
[ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10
[ 3697.859637] ? __pfx_assign_work+0x10/0x10
[ 3697.859896] ? lock_is_held_type+0x7b/0x110
[ 3697.860146] worker_thread+0x975/0xee0
[ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 3697.860830] ? __kthread_parkme+0x21e/0x260
[ 3697.861105] kthread+0x3a6/0x490
[ 3697.861423] ? __pfx_worker_thread+0x10/0x10
[ 3697.861643] ? __pfx_kthread+0x10/0x10
[ 3697.861878] ret_from_fork+0x55a/0xa20
[ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10
[ 3697.862480] ? __pfx_kthread+0x10/0x10
[ 3697.862714] ret_from_fork_asm+0x1a/0x30
[ 3697.862965] </TASK>
[ 3697.863039]
[ 3697.938882] Allocated by task 20761:
[ 3697.940257] kasan_save_track+0x3e/0x80
[ 3697.941782] __kasan_kmalloc+0x72/0x90
[ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0
[ 3697.944948] handle_generic_event+0x59b/0x750
[ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560
[ 3697.946977] genl_rcv_msg+0x67c/0x900
[ 3697.947224] netlink_rcv_skb+0x286/0x580
[ 3697.947488] genl_rcv+0x2d/0x80
[ 3
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: release pending child sockets outside the handler lock
smbdirect_socket_destroy() releases the listener's pending/ready child
sockets while still holding the listener's handler lock, the
&id_priv->handler_mutex taken via rdma_lock_handler(), not
sc->listen.lock, and before the listener's own rdma_destroy_id().
That ordering has one real consequence and one cosmetic one.
The real one: smbdirect_socket_release() drops the child's last
reference, which destroys the child's cm_id. Doing that before the
listener's rdma_destroy_id() lets _cma_cancel_listens(), running from
the listener's _destroy_id(), walk an already freed child id_priv,
which KASAN catches as a slab-use-after-free during listener shutdown:
[ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469/0x1560
[ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652
[ 4758.913262] Call Trace:
[ 4758.913267] <TASK>
[ 4758.913299] __mutex_lock+0x1469/0x1560
[ 4758.913408] _cma_cancel_listens+0x312/0x3b0
[ 4758.913413] _destroy_id+0x363/0xee0
[ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440
[ 4758.913443] smbdirect_socket_release+0x124/0x230
[ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190
[ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0
[ 4758.913463] kill_server_store+0x1fb/0x2b0
[ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0
[ 4758.913507] vfs_write+0x5e7/0xc70
[ 4758.913528] ksys_write+0x12a/0x210
[ 4758.913541] do_syscall_64+0x135/0x460
[ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f
The cosmetic one: releasing a child recurses into
smbdirect_socket_destroy(), which takes the child's own
rdma_lock_handler() lock nested under the listener's. The listener's
and the child's cm_id are always different instances, so this cannot
deadlock for real; the CM core itself nests a new connection id's
handler_mutex under the listening id's in cma_ib_req_handler(). But
lockdep only sees one lock class, reports possible recursive locking,
and then disables itself, hiding real locking bugs for the rest of the
run:
[ 2424.579653] WARNING: possible recursive locking detected
[ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted
[ 2424.582548] --------------------------------------------
[ 2424.584500] ksmbd.control/8854 is trying to acquire lock:
[ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.590590]
[ 2424.590590] but task is already holding lock:
[ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.594178]
[ 2424.594178] other info that might help us debug this:
[ 2424.596634] Possible unsafe locking scenario:
[ 2424.596634]
[ 2424.598841] CPU0
[ 2424.599765] ----
[ 2424.600695] lock(&id_priv->handler_mutex);
[ 2424.601836] lock(&id_priv->handler_mutex);
[ 2424.602590]
[ 2424.602590] *** DEADLOCK ***
[ 2424.602590]
[ 2424.604512] May be due to missing lock nesting notation
Splice the pending/ready children onto a local list under the
listener's listen.lock, while the handler lock is held so a concurrent
CM CONNECT_REQUEST cannot add more, but defer the actual
smbdirect_socket_release() calls until after the listener's cm_id has
been destroyed and its handler lock dropped. The children are
independent sockets whose teardown needs neither the listener's
handler lock nor its cm_id.
Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a
kcov-dataflow [1] coverage vector: it folds each instrumented
comparison/argument's runtime operand value together with its PC (the
default arm mixes them as pc⊕val) so that a new operand value at a known
site counts as new coverage.
[1] https://lwn.net/Articles/1077606/
[2] https://github.com/yskzalloc/kcov-dataflow |
