From: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
To: Bernard Metzler <bernard.metzler@linux.dev>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>
Cc: Shuangpeng Bai <shuangpeng.kernel@gmail.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] RDMA/siw: slab-use-after-free in siw_cep_set_free
Date: Thu, 5 Nov 2026 12:37:47 -0500 [thread overview]
Message-ID: <20261105173754.660897-1-shuangpeng.kernel@gmail.com> (raw)
Hi Kernel Maintainers,
I hit the following report while testing current upstream kernel:
KASAN: slab-use-after-free in _raw_spin_lock_irqsave
This is a SIW CEP lifetime bug reached from `siw_cep_set_free()`'s
`wake_up(&cep->waitq)`.
on commit: 05441d697f7f9a927264f4058cbbc6a03dfcac9d (7.4.0-rc1)
To help trigger the bug more reliably, I applied a minimal diagnostic patch
that only adds delays and print statements.
A related CEP lifetime concern was raised in:
Link: https://lore.kernel.org/linux-rdma/05b91f98-e3a3-793a-9197-f09d84acfaf7@linux.dev/
This report provides a reproducible TX-worker race in
`siw_qp_cm_drop()` around the `siw_cep_set_free()` unlock-to-
`wake_up()` window.
The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/0ef6a31bdb90f4f245b5f86b76775bc5
I am happy to test debug patches or provide additional information.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
==================================================================
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave (include/linux/instrumented.h:112 include/linux/atomic/atomic-instrumented.h:1300 include/asm-generic/qspinlock.h:112 include/linux/spinlock.h:188 include/linux/spinlock_api_smp.h:156 kernel/locking/spinlock.c:181)
Write of size 4 at addr ffff88810d742230 by task siw_tx/1/78
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
kasan_check_range (mm/kasan/generic.c:200)
_raw_spin_lock_irqsave (include/linux/instrumented.h:112 include/linux/atomic/atomic-instrumented.h:1300 include/asm-generic/qspinlock.h:112 include/linux/spinlock.h:188 include/linux/spinlock_api_smp.h:156 kernel/locking/spinlock.c:181)
__wake_up (kernel/sched/wait.c:124 kernel/sched/wait.c:146)
siw_qp_cm_drop (drivers/infiniband/sw/siw/siw_cm.c:517)
siw_sq_resume (drivers/infiniband/sw/siw/siw_qp_tx.c:1190)
siw_run_sq (drivers/infiniband/sw/siw/siw_qp_tx.c:1278)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
</TASK>
Allocated by task 340 on cpu 1 at 18.058572s:
kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
__kasan_kmalloc (mm/kasan/common.c:409 mm/kasan/common.c:426)
siw_cep_alloc (include/linux/slab.h:991 include/linux/slab.h:1312 drivers/infiniband/sw/siw/siw_cm.c:210)
siw_connect (drivers/infiniband/sw/siw/siw_cm.c:1487)
iw_cm_connect (drivers/infiniband/core/iwcm.c:730)
rdma_connect_locked (drivers/infiniband/core/cma.c:4490 drivers/infiniband/core/cma.c:4530)
rdma_connect_ece (drivers/infiniband/core/cma.c:4562 drivers/infiniband/core/cma.c:4585)
ucma_connect (drivers/infiniband/core/ucma.c:1148)
ucma_write (drivers/infiniband/core/ucma.c:1869)
vfs_write (fs/read_write.c:685)
ksys_write (fs/read_write.c:739)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Freed by task 340 on cpu 1 at 18.111920s:
kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
kasan_save_free_info (mm/kasan/generic.c:584)
__kasan_slab_free (mm/kasan/common.c:264 mm/kasan/common.c:296)
kfree (include/linux/kasan.h:235 mm/slub.c:2780 mm/slub.c:6630 mm/slub.c:6923)
siw_destroy_qp (drivers/infiniband/sw/siw/siw_verbs.c:635)
ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2182)
uverbs_free_qp (drivers/infiniband/core/uverbs_std_types_qp.c:34)
destroy_hw_idr_uobject (drivers/infiniband/core/rdma_core.c:579)
uverbs_destroy_uobject (drivers/infiniband/core/rdma_core.c:172)
uobj_destroy (drivers/infiniband/core/rdma_core.c:240)
ib_uverbs_cmd_verbs (drivers/infiniband/core/uverbs_ioctl.c:379 drivers/infiniband/core/uverbs_ioctl.c:526)
ib_uverbs_ioctl (drivers/infiniband/core/uverbs_ioctl.c:555)
__se_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:597 fs/ioctl.c:583)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address belongs to the object at ffff88810d742200
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 48 bytes inside of
freed 256-byte region [ffff88810d742200, ffff88810d742300)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10d742
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x200000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000040 ffff888100041b40 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 0200000000000040 ffff888100041b40 dead000000000100 dead000000000122
head: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 0200000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88810d742100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88810d742180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88810d742200: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88810d742280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88810d742300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Best,
Shuangpeng
reply other threads:[~2026-11-05 17:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261105173754.660897-1-shuangpeng.kernel@gmail.com \
--to=shuangpeng.kernel@gmail.com \
--cc=bernard.metzler@linux.dev \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®