All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.