| db82fbe4 | 05-Aug-2026 |
Yunseong Kim <yunseong.kim@est.tech> |
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,
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
Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Signed-off-by: Yunseong Kim <yunseong.kim@est.tech> Reviewed-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
show more ...
|
| 76fa42c0 | 05-Aug-2026 |
Yunseong Kim <yunseong.kim@est.tech> |
smb: smbdirect: avoid recursive listen.lock during cleanup
__smbdirect_socket_schedule_cleanup() and smbdirect_socket_cleanup_work() take sc->listen.lock and walk the listener's pending list, recurs
smb: smbdirect: avoid recursive listen.lock during cleanup
__smbdirect_socket_schedule_cleanup() and smbdirect_socket_cleanup_work() take sc->listen.lock and walk the listener's pending list, recursing into smbdirect_socket_schedule_cleanup() for each child, and every child takes its own listen.lock inside that walk.
This cannot deadlock for real: the nesting is strictly listener into child, a child never listens, so the outer and the inner lock are always different instances. lockdep only tracks lock classes, though; it sees the same class acquired twice and reports a possible recursive locking deadlock. This change therefore works around a lockdep limitation rather than fixing a real hang, but the report is still worth avoiding: lockdep disables itself after the first splat and then hides real locking bugs for the rest of the run.
Only a socket that was a listener owns a populated listen.ready/pending list; a child has empty lists and nothing to do in these blocks. Guard both of them with sc->listen.backlog != -1, the "was a listener" marker that smbdirect_socket_destroy() already uses: listen.backlog leaves its initial -1 exactly once, when smbdirect_socket_listen() succeeds. The alternative !sc->accept.listener test reads as "not a listener" while meaning the opposite, and it is also true for an accepted child, whose accept.listener has been cleared on hand-over. With the guard the walk only runs for a listener and never nests a child's listen.lock under it; a pending child stays on its listener's list for the free path (smbdirect_socket_destroy) to reap.
[ 741.705044] WARNING: possible recursive locking detected [ 741.705403] 7.1.0-next-20260623+ #75 Not tainted [ 741.705695] -------------------------------------------- [ 741.706022] ksmbd.control/18502 is trying to acquire lock: [ 741.706379] ffff888108d612f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.707008] [ 741.707008] but task is already holding lock: [ 741.707396] ffff8881087642f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.708025] [ 741.708025] other info that might help us debug this: [ 741.708448] Possible unsafe locking scenario: [ 741.708448] [ 741.708845] CPU0 [ 741.709016] ---- [ 741.709186] lock(&sc->listen.lock); [ 741.709453] lock(&sc->listen.lock); [ 741.709705] [ 741.709705] *** DEADLOCK *** [ 741.709705] [ 741.710095] May be due to missing lock nesting notation [ 741.710095] [ 741.710663] 6 locks held by ksmbd.control/18502: [ 741.710975] #0: ffff888109e51420 (sb_writers#7){.+.+}-{0:0}, at: vfs_write+0x1e7/0xc70 [ 741.711561] #1: ffff888126ec3880 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x1be/0x4d0 [ 741.712147] #2: ffff888102af17b0 (kn->active#45){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x205/0x4d0 [ 741.712803] #3: ffffffff85ad1e00 (ctrl_lock){+.+.}-{4:4}, at: kill_server_store+0x1e0/0x2b0 [ 741.713381] #4: ffffffff85ad41a0 (init_lock){+.+.}-{4:4}, at: ksmbd_conn_transport_destroy+0x5b/0x3c0 [ 741.713995] #5: ffff8881087642f8 (&sc->listen.lock){....}-{3:3}, at: __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.714736] [ 741.714736] stack backtrace: [ 741.715038] CPU: 4 UID: 0 PID: 18502 Comm: ksmbd.control Not tainted 7.1.0-next-20260623+ #75 PREEMPT(lazy) [ 741.715043] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 741.715046] Call Trace: [ 741.715049] <TASK> [ 741.715052] dump_stack_lvl+0x77/0xa0 [ 741.715058] print_deadlock_bug+0x279/0x290 [ 741.715065] __lock_acquire+0x272a/0x2e30 [ 741.715070] ? stack_trace_save+0xae/0x100 [ 741.715075] ? smb_direct_logging_vaprintf+0x1a0/0x230 [ 741.715079] ? __pfx_smb_direct_logging_vaprintf+0x10/0x10 [ 741.715082] ? __timer_delete+0x58/0x320 [ 741.715087] lock_acquire+0xd3/0x270 [ 741.715091] ? __smbdirect_socket_schedule_cleanup+0x719/0xd70 [ 741.715095] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 741.715099] _raw_spin_lock_irqsave+0x42/0x60 [ 741.715105] ? __smbdirect_socket_schedule_cleanup+0x719/0xd70
Note the two addresses above: ffff888108d612f8 is the child's lock, ffff8881087642f8 the listener's, always distinct objects.
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
Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Signed-off-by: Yunseong Kim <yunseong.kim@est.tech> Reviewed-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
show more ...
|
| 383a9480 | 21-Jul-2026 |
Yunseong Kim <yunseong.kim@est.tech> |
smb: smbdirect: destroy QP before mem pools on accept failure
On the rdma_accept_failed error path of smbdirect_accept_connect_request(), the receive io posted just above is owned by the QP (recv_io
smb: smbdirect: destroy QP before mem pools on accept failure
On the rdma_accept_failed error path of smbdirect_accept_connect_request(), the receive io posted just above is owned by the QP (recv_io is set to NULL after a successful post). The error path fell through to smbdirect_connection_destroy_mem_pools() before smbdirect_connection_destroy_qp(), so the mem pools and the recv_io slab cache were destroyed while that recv_io was still outstanding on the QP.
The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what runs the recv completion that returns the recv_io to the free list, so destroying the pools first leaves the object outstanding at kmem_cache_destroy() time ("Slab cache still has objects") and later frees it into an already-destroyed mempool (mempool_free_bulk NULL-pointer dereference).
Give rdma_accept_failed its own teardown that drains the QP first, then destroys the mem pools, and returns. The remaining labels (post_recv_io_failed onward) run before the recv_io was ever posted, so they keep the mem-pools-then-qp order.
The outstanding recv_io at kmem_cache_destroy() time:
[ 3487.344647] ============================================================================= [ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown() [ 3487.356078] ----------------------------------------------------------------------------- [ 3487.356078] [ 3487.356738] Object 0xffff8881511c3440 @offset=13376 [ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempool_alloc_noprof+0x18c/0x290 [ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780 [ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80 [ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.362779] cma_cm_event_handler+0x9c/0x230 [ 3487.363096] cma_ib_req_handler+0x2682/0x45d0 [ 3487.363414] cm_process_work+0x56/0x3d0 [ 3487.363676] cm_work_handler+0x8a0e/0xd000 [ 3487.367496] process_scheduled_works+0xa07/0x13a0 [ 3487.367859] worker_thread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] ret_from_fork+0x3a8/0x7a0 [ 3487.368704] ret_from_fork_asm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2) [ 3487.372840] ------------[ cut here ]------------ [ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254 [ 3487.373759] Modules linked in: [ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3487.374778] Tainted: [B]=BAD_PAGE [ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] Workqueue: ib_cm cm_work_handler [ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30 [ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093 [ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80 [ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080 [ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410 [ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210 [ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300 [ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3487.390440] PKRU: 55555554 [ 3487.390641] Call Trace: [ 3487.390826] <TASK> [ 3487.391209] __kmem_cache_shutdown+0x1aa/0x2b0 [ 3487.392062] ? smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.393565] kmem_cache_destroy+0x9d/0x180 [ 3487.398663] smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.403534] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ 3487.407562] smbdirect_accept_connect_request+0x95c/0x1b80 [ 3487.412391] ? __pfx_smbdirect_accept_connect_request+0x10/0x10 [ 3487.416753] ? do_raw_spin_lock+0x130/0x300 [ 3487.420623] ? smbdirect_socket_set_initial_parameters+0x28b/0x6a0 [ 3487.424322] ? lock_acquire+0x4c/0x270 [ 3487.424409] ksmbd: can't change a file to a directory [ 3487.426321] ? trace_irq_enable+0x36/0x120 [ 3487.429144] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.432606] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3487.433595] ? trace_cm_event_handler+0x51/0x170 [ 3487.435183] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3487.435646] ? cma_listen_handler+0xf6/0x150 [ 3487.435975] cma_cm_event_handler+0x9c/0x230 [ 3487.436288] cma_ib_req_handler+0x2682/0x45d0 [ 3487.439039] ? __pfx_cma_ib_req_handler+0x10/0x10 [ 3487.439540] ? __pfx_roce_resolve_route_from_path+0x10/0x10 [ 3487.439972] ? stack_depot_save_flags+0x34/0x840 [ 3487.440374] ? __xas_nomem+0xa9/0x410 [ 3487.443356] ? xas_clear_mark+0x26c/0x4a0 [ 3487.443673] cm_process_work+0x56/0x3d0 [ 3487.443969] ? _raw_spin_unlock_irq+0x28/0x50 [ 3487.444317] cm_work_handler+0x8a0e/0xd000 [ 3487.444624] ? __pfx_cm_work_handler+0x10/0x10 [ 3487.444971] ? pwq_dec_nr_in_flight+0xa73/0xdf0 [ 3487.445344] ? __pfx_pwq_dec_nr_in_flight+0x10/0x10 [ 3487.445737] ? lock_acquire+0x4c/0x270 [ 3487.448833] ? process_scheduled_works+0x995/0x13a0 [ 3487.449230] ? process_scheduled_works+0x995/0x13a0 [ 3487.449588] process_scheduled_works+0xa07/0x13a0 [ 3487.449938] ? __pfx_process_scheduled_works+0x10/0x10 [ 3487.450334] ? do_raw_spin_lock+0x130/0x300 [ 3487.450639] ? assign_work+0x3bb/0x5c0 [ 3487.450916] worker_thread+0x7c9/0xc80 [ 3487.451211] kthread+0x341/0x430 [ 3487.451453] ? __pfx_worker_thread+0x10/0x10 [ 3487.451756] ? __pfx_kthread+0x10/0x10 [ 3487.454814] ret_from_fork+0x3a8/0x7a0 [ 3487.455114] ? __pfx_ret_from_fork+0x10/0x10 [ 3487.455450] ? __switch_to+0xb76/0x1110 [ 3487.455772] ? __pfx_kthread+0x10/0x10 [ 3487.456081] ret_from_fork_asm+0x1a/0x30 [ 3487.456384] </TASK> [ 3487.456549] irq event stamp: 0 [ 3487.456767] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 3487.460124] hardirqs last disabled at (0): [<ffffffff81684648>] copy_process+0xa08/0x3a10 [ 3487.460726] softirqs last enabled at (0): [<ffffffff81684648>] copy_process+0xa08/0x3a10 [ 3487.461328] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 3487.461778] ---[ end trace 0000000000000000 ]--- [ 3487.543875] ksmbd: can't change a file to a directory [ 3487.599675] ksmbd: can't change a file to a directory [ 3487.626694] ksmbd: can't change a file to a directory [ 3487.824687] ksmbd: can't change a file to a directory [ 3487.871840] ksmbd: can't change a file to a directory [ 3487.986207] ------------[ cut here ]------------ [ 3487.987157] kmem_cache_destroy smbdirect_recv_io_cache_ffff88811ba99000: Slab cache still has objects when called from smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3487.987183] WARNING: mm/slab_common.c:572 at kmem_cache_destroy+0x15c/0x180, CPU#6: kworker/6:84/22254 [ 3487.999821] Modules linked in: [ 3488.001902] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B W 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3488.008289] Tainted: [B]=BAD_PAGE, [W]=WARN [ 3488.010459] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3488.014502] Workqueue: ib_cm cm_work_handler [ 3488.017790] RIP: 0010:kmem_cache_destroy+0x16a/0x180 [ 3488.020662] Code: fd ff 48 8b 3d 2f c0 9c 06 48 89 de 5b 41 5e 5d e9 5b a3 0e 00 48 8d 3d a4 07 12 04 48 8b 53 58 48 c7 c6 91 9d 3e 85 4c 89 f1 <67> 48 0f b9 3a e9 33 ff ff ff 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3488.028077] RSP: 0018:ffff888220fc70b8 EFLAGS: 00010202 [ 3488.032038] RAX: 0000000000000001 RBX: ffff88810955e640 RCX: ffffffff822bc079 [ 3488.035742] RDX: ffff88812404ec40 RSI: ffffffff853e9d91 RDI: ffffffff85f7ac50 [ 3488.037830] RBP: 0000000000000001 R08: ffff8883aef3e843 R09: 1ffff11075de7d08 [ 3488.041076] R10: dffffc0000000000 R11: ffffed1075de7d09 R12: 1ffff11024fa6c3c [ 3488.045376] R13: ffff888127d361e8 R14: ffffffff822bc079 R15: ffff88811ba99538 [ 3488.049073] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3488.052515] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3488.054934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3488.058529] PKRU: 55555554 [ 3488.060542] Call Trace: [ 3488.061595] <TASK> [ 3488.062006] smbdirect_connection_destroy_mem_pools+0x239/0x300 [ 3488.066041] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ 3488.068620] smbdirect_accept_connect_request+0x95c/0x1b80 [ 3488.071594] ? __pfx_smbdirect_accept_connect_request+0x10/0x10 [ 3488.073218] ksmbd: not allow base filename in rename [ 3488.074751] ? do_raw_spin_lock+0x130/0x300 [ 3488.076792] ksmbd: can't change a file to a directory [ 3488.077942] ? smbdirect_socket_set_initial_parameters+0x28b/0x6a0 [ 3488.080143] ? lock_acquire+0x4c/0x270 [ 3488.080747] ? trace_irq_enable+0x36/0x120 [ 3488.081400] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3488.085089] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3488.089333] ? trace_cm_event_handler+0x51/0x170 [ 3488.092637] ? __pfx_smbdirect_listen_rdma_event_handler+0x10/0x10 [ 3488.095741] ? cma_listen_handler+0xf6/0x150 [ 3488.099638] cma_cm_event_handler+0x9c/0x230 [ 3488.101552] cma_ib_req_handler+0x2682/0x45d0 [ 3488.104571] ? __pfx_cma_ib_req_handler+0x10/0x10 [ 3488.106790] ? __pfx_roce_resolve_route_from_path+0x10/0x10 [ 3488.109799] ? stack_depot_save_flags+0x34/0x840 [ 3488.112174] ? __xas_nomem+0xa9/0x410 [ 3488.114217] ? xas_clear_mark+0x26c/0x4a0 [ 3488.116854] cm_process_work+0x56/0x3d0 [ 3488.118179] ? _raw_spin_unlock_irq+0x28/0x50 [ 3488.120034] cm_work_handler+0x8a0e/0xd000 [ 3488.121677] ? __pfx_cm_work_handler+0x10/0x10 [ 3488.123682] ? pwq_dec_nr_in_flight+0xa73/0xdf0 [ 3488.126928] ? __pfx_pwq_dec_nr_in_flight+0x10/0x10 [ 3488.129390] ? lock_acquire+0x4c/0x270 [ 3488.131432] ? process_scheduled_works+0x995/0x13a0 [ 3488.132694] ksmbd: can't change a file to a directory [ 3488.136702] ? process_scheduled_works+0x995/0x13a0 [ 3488.140060] process_scheduled_works+0xa07/0x13a0 [ 3488.143379] ? __pfx_process_scheduled_works+0x10/0x10 [ 3488.147221] ? do_raw_spin_lock+0x130/0x300 [ 3488.150790] ? assign_work+0x3bb/0x5c0 [ 3488.154259] worker_thread+0x7c9/0xc80 [ 3488.155730] kthread+0x341/0x430 [ 3488.158309] ? __pfx_worker_thread+0x10/0x10 [ 3488.160865] ? __pfx_kthread+0x10/0x10 [ 3488.164384] ret_from_fork+0x3a8/0x7a0 [ 3488.167020] ? __pfx_ret_from_fork+0x10/0x10 [ 3488.170050] ? __switch_to+0xb76/0x1110 [ 3488.171809] ? __pfx_kthread+0x10/0x10 [ 3488.174955] ret_from_fork_asm+0x1a/0x30 [ 3488.175605] </TASK> [ 3488.176206] irq event stamp: 0 [ 3488.179360] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 3488.186521] hardirqs last disabled at (0): [<ffffffff81684648>] copy_process+0xa08/0x3a10 [ 3488.191889] softirqs last enabled at (0): [<ffffffff81684648>] copy_process+0xa08/0x3a10 [ 3488.196853] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 3488.200870] ---[ end trace 0000000000000000 ]---
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
Fixes: eb3ed1e9048c ("smb: smbdirect: introduce smbdirect_accept_connect_request()") Signed-off-by: Yunseong Kim <yunseong.kim@est.tech> Acked-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
show more ...
|
| 9900b9fe | 29-Apr-2026 |
Yi Kuo <yi@yikuo.dev> |
smb: smbdirect: fix MR registration for coalesced SG lists
ib_dma_map_sg() modifies the provided scatterlist and returns the number of mapped entries, which can be fewer than the requested mr->sgt.n
smb: smbdirect: fix MR registration for coalesced SG lists
ib_dma_map_sg() modifies the provided scatterlist and returns the number of mapped entries, which can be fewer than the requested mr->sgt.nents if the DMA controller coalesces contiguous memory segments. Passing the original, uncoalesced count to ib_map_mr_sg() causes memory registration failures if coalescing actually occurs.
Capture the actual mapped count returned by ib_dma_map_sg() and pass it to ib_map_mr_sg() to ensure correct MR registration.
Also update the ib_dma_map_sg() error logging to drop the error pointer formatting, since the return value is an integer count rather than an error code.
Ensure a proper error code (-EIO) is assigned when DMA mapping or MR registration fails.
Fixes: de5ef8ec3c46 ("smb: smbdirect: introduce smbdirect_mr.c with client mr code") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221408 Reviewed-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Yi Kuo <yi@yikuo.dev> Signed-off-by: Steve French <stfrench@microsoft.com>
show more ...
|