[PATCH] RDMA/rxe: Use validated num_sge in local buffer

[PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Nicolas Morey]

For both SRQ and non-SRQ receive paths, the WQE is copied into a local
buffer to provide a kernel-owned, validated copy. While calculating the
memcpy size from the validated num_sge prevents overflow during the
copy, memcpy() itself still copies num_sge from shared memory.

A concurrent userspace modification before or during memcpy() leaves
an unvalidated num_sge in the local buffer, leading to potential
out-of-bounds reads in rxe_resp_check_length() and copy_data().

Explicitly assign the validated num_sge to the local buffer after the
copy to prevent this race.

Fixes: 22b8fbded65b ("RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe")
Fixes: d6ab440240a0 ("RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path")
Signed-off-by: Nicolas Morey <nmorey@suse.com>
---
 drivers/infiniband/sw/rxe/rxe_resp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
index 02b16e2b49b8..cd51042857d6 100644
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -288,6 +288,7 @@ static enum resp_states get_srq_wqe(struct rxe_qp *qp)
 	}
 	size = sizeof(*wqe) + num_sge * sizeof(struct rxe_sge);
 	memcpy(&qp->resp.srq_wqe, wqe, size);
+	qp->resp.srq_wqe.wqe.dma.num_sge = num_sge;
 
 	qp->resp.wqe = &qp->resp.srq_wqe.wqe;
 	queue_advance_consumer(q, QUEUE_TYPE_FROM_CLIENT);
@@ -328,6 +329,7 @@ static enum resp_states rxe_get_recv_wqe(struct rxe_qp *qp)
 	}
 	size = sizeof(*wqe) + num_sge * sizeof(struct rxe_sge);
 	memcpy(&qp->resp.srq_wqe, wqe, size);
+	qp->resp.srq_wqe.wqe.dma.num_sge = num_sge;
 
 	qp->resp.wqe = &qp->resp.srq_wqe.wqe;
 	return RESPST_CHK_LENGTH;
-- 
2.54.0

Re: [PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Zhu Yanjun]

在 2026/9/7 9:15, Nicolas Morey 写道:
> For both SRQ and non-SRQ receive paths, the WQE is copied into a local
> buffer to provide a kernel-owned, validated copy. While calculating the
> memcpy size from the validated num_sge prevents overflow during the
> copy, memcpy() itself still copies num_sge from shared memory.
> 
> A concurrent userspace modification before or during memcpy() leaves
> an unvalidated num_sge in the local buffer, leading to potential
> out-of-bounds reads in rxe_resp_check_length() and copy_data().
> 

Hi Nicolas,

Thanks for the patch. The logic makes total sense to prevent the TOCTOU 
race condition after memcpy.

Just out of curiosity, do you happen to have a reproducer or a POC 
script that demonstrates this race in practice?

It would be great to know if this can be reliably reproduced or 
integrated into testing setups (like rdma-core tests, or 
tools/testing/selftests/rdma) to catch similar double-read issues in the 
future.

Thanks a lot for your effort.

Zhu Yanjun

> Explicitly assign the validated num_sge to the local buffer after the
> copy to prevent this race.
> 
> Fixes: 22b8fbded65b ("RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe")
> Fixes: d6ab440240a0 ("RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path")
> Signed-off-by: Nicolas Morey <nmorey@suse.com>
> ---
>   drivers/infiniband/sw/rxe/rxe_resp.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> index 02b16e2b49b8..cd51042857d6 100644
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> @@ -288,6 +288,7 @@ static enum resp_states get_srq_wqe(struct rxe_qp *qp)
>   	}
>   	size = sizeof(*wqe) + num_sge * sizeof(struct rxe_sge);
>   	memcpy(&qp->resp.srq_wqe, wqe, size);
> +	qp->resp.srq_wqe.wqe.dma.num_sge = num_sge;
>   
>   	qp->resp.wqe = &qp->resp.srq_wqe.wqe;
>   	queue_advance_consumer(q, QUEUE_TYPE_FROM_CLIENT);
> @@ -328,6 +329,7 @@ static enum resp_states rxe_get_recv_wqe(struct rxe_qp *qp)
>   	}
>   	size = sizeof(*wqe) + num_sge * sizeof(struct rxe_sge);
>   	memcpy(&qp->resp.srq_wqe, wqe, size);
> +	qp->resp.srq_wqe.wqe.dma.num_sge = num_sge;
>   
>   	qp->resp.wqe = &qp->resp.srq_wqe.wqe;
>   	return RESPST_CHK_LENGTH;

Re: [PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Nicolas Morey]

On 2026-09-07 23:20, Zhu Yanjun wrote:
> 在 2026/9/7 9:15, Nicolas Morey 写道:
>> For both SRQ and non-SRQ receive paths, the WQE is copied into a local
>> buffer to provide a kernel-owned, validated copy. While calculating the
>> memcpy size from the validated num_sge prevents overflow during the
>> copy, memcpy() itself still copies num_sge from shared memory.
>>
>> A concurrent userspace modification before or during memcpy() leaves
>> an unvalidated num_sge in the local buffer, leading to potential
>> out-of-bounds reads in rxe_resp_check_length() and copy_data().
>>
> 
> Hi Nicolas,
> 
> Thanks for the patch. The logic makes total sense to prevent the TOCTOU race condition after memcpy.
> 
> Just out of curiosity, do you happen to have a reproducer or a POC script that demonstrates this race in practice?
> 
> It would be great to know if this can be reliably reproduced or integrated into testing setups (like rdma-core tests, or tools/testing/selftests/rdma) to catch similar double-read issues in the future.
> 

No reproducer or PoC sadly. I haven't tried to make one though.
This got caught by one of our AI tools when checking the backport of CVE-2026-74377.

I assumed from the 2 existing fixes (ending up as CVEs) that this could happened.

Nicolas

Re: [PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Zhu Yanjun]

在 2026/9/7 14:44, Nicolas Morey 写道:
> On 2026-09-07 23:20, Zhu Yanjun wrote:
>> 在 2026/9/7 9:15, Nicolas Morey 写道:
>>> For both SRQ and non-SRQ receive paths, the WQE is copied into a local
>>> buffer to provide a kernel-owned, validated copy. While calculating the
>>> memcpy size from the validated num_sge prevents overflow during the
>>> copy, memcpy() itself still copies num_sge from shared memory.
>>>
>>> A concurrent userspace modification before or during memcpy() leaves
>>> an unvalidated num_sge in the local buffer, leading to potential
>>> out-of-bounds reads in rxe_resp_check_length() and copy_data().
>>>
>>
>> Hi Nicolas,
>>
>> Thanks for the patch. The logic makes total sense to prevent the TOCTOU race condition after memcpy.
>>
>> Just out of curiosity, do you happen to have a reproducer or a POC script that demonstrates this race in practice?
>>
>> It would be great to know if this can be reliably reproduced or integrated into testing setups (like rdma-core tests, or tools/testing/selftests/rdma) to catch similar double-read issues in the future.
>>
> 
> No reproducer or PoC sadly. I haven't tried to make one though.
> This got caught by one of our AI tools when checking the backport of CVE-2026-74377.

Hi, Nicolas

Thanks for sharing this. Could you clarify whether your AI tool detected 
this purely through static analysis (and provided a suggested fix), or 
if it actually triggered a runtime bug with a backtrace/calltrace?

If you have a calltrace, please share it—that would help a lot in 
understanding the issue. Also, if this was flagged and fixed by a 
specific AI tool, adding an Assisted-by: tag (or referencing the tool in 
the commit description) would be appropriate.

Thanks,

Zhu Yanjun

> 
> I assumed from the 2 existing fixes (ending up as CVEs) that this could happened.
> 
> Nicolas

Re: [PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Nicolas Morey]

On 2026-09-08 05:07, Zhu Yanjun wrote:
> 在 2026/9/7 14:44, Nicolas Morey 写道:
>> On 2026-09-07 23:20, Zhu Yanjun wrote:
>>> 在 2026/9/7 9:15, Nicolas Morey 写道:
>>>> For both SRQ and non-SRQ receive paths, the WQE is copied into a local
>>>> buffer to provide a kernel-owned, validated copy. While calculating the
>>>> memcpy size from the validated num_sge prevents overflow during the
>>>> copy, memcpy() itself still copies num_sge from shared memory.
>>>>
>>>> A concurrent userspace modification before or during memcpy() leaves
>>>> an unvalidated num_sge in the local buffer, leading to potential
>>>> out-of-bounds reads in rxe_resp_check_length() and copy_data().
>>>>
>>>
>>> Hi Nicolas,
>>>
>>> Thanks for the patch. The logic makes total sense to prevent the TOCTOU race condition after memcpy.
>>>
>>> Just out of curiosity, do you happen to have a reproducer or a POC script that demonstrates this race in practice?
>>>
>>> It would be great to know if this can be reliably reproduced or integrated into testing setups (like rdma-core tests, or tools/testing/selftests/rdma) to catch similar double-read issues in the future.
>>>
>>
>> No reproducer or PoC sadly. I haven't tried to make one though.
>> This got caught by one of our AI tools when checking the backport of CVE-2026-74377.
> 
> Hi, Nicolas
> 
> Thanks for sharing this. Could you clarify whether your AI tool detected this purely through static analysis (and provided a suggested fix), or if it actually triggered a runtime bug with a backtrace/calltrace?
> 
> If you have a calltrace, please share it—that would help a lot in understanding the issue. Also, if this was flagged and fixed by a specific AI tool, adding an Assisted-by: tag (or referencing the tool in the commit description) would be appropriate.
> 
> Thanks,
> 
> Zhu Yanjun
> 

Hi Zhu,

The tool is a LLM static analyser that simply detected that d6ab440240a0 ("RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path") was a valid patch but did not fix the whole issue. It did not suggest any breaker PoC nor any fix.
All the rest is human (me) made.
Does that warrant an Assisted-by tag ? 
It seems sashiko picked the same issue for 22b8fbded65b ("RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe")
https://sashiko.dev/#/patchset/20260518215040.1598586-1-tristan%40talencesecurity.com

> If a concurrent userspace thread modifies wqe->dma.num_sge after the
> bounds check but before the memcpy completes, doesn't this copy the
> unvalidated value into the kernel heap?

By tweaking the reproducer from Tristan, I have been able to reproduce it once out of sheer luck I think:
==================================================================
BUG: KASAN: slab-out-of-bounds in rxe_receiver+0x8109/0x9ec0 [rdma_rxe]
Read of size 4 at addr ffff88812c4867f8 by task kworker/u9:6/361

CPU: 0 UID: 0 PID: 361 Comm: kworker/u9:6 Tainted: G            E       7.3.0-rc2-00006-g28924df2a08f #3 PREEMPT(full)  318a88bba3045f81bad31a7694727561b4bd4965
Tainted: [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
Workqueue: rxe_wq do_work [rdma_rxe]
Call Trace:
 <TASK>
 dump_stack_lvl+0x4b/0x70
 print_report+0x153/0x4b5
 ? __pfx__raw_spin_lock_irqsave+0x10/0x10
 ? stack_trace_save+0x93/0xd0
 kasan_report+0xbc/0xf0
 ? rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 ? rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 ? pick_task_fair+0x12e/0x1b50
 ? __pfx_rxe_receiver+0x10/0x10 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 ? __pfx__raw_spin_lock_irqsave+0x10/0x10
 ? hrtimer_start_range_ns+0xe7/0x320
 ? ktime_get+0xe3/0x170
 ? _raw_spin_unlock+0xe/0x30
 ? _raw_spin_lock_irqsave+0x8a/0xf0
 ? __pfx__raw_spin_lock_irqsave+0x10/0x10
 ? __pfx_rxe_receiver+0x10/0x10 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 do_work+0x149/0x610 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
 process_one_work+0x726/0x10a0
 ? __pfx___schedule+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? _raw_spin_lock_irq+0x85/0xe0
 ? __pfx__raw_spin_lock_irq+0x10/0x10
 worker_thread+0x500/0xd70
 ? __kthread_parkme+0x8d/0x170
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x329/0x410
 ? recalc_sigpending+0x15c/0x200
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x4cf/0x760
 ? __pfx_ret_from_fork+0x10/0x10
 ? __switch_to+0x575/0x11c0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Allocated by task 1698:
 kasan_save_stack+0x20/0x40
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x9a/0xb0
 __kmalloc_noprof+0x209/0x560
 create_qp.part.0+0x760/0x9d0 [ib_core]
 ib_create_qp_user+0xa2/0x500 [ib_core]
 ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x99b/0x12af [ib_uverbs]
 ib_uverbs_cmd_verbs+0x214b/0x32d0 [ib_uverbs]
 ib_uverbs_ioctl+0x131/0x200 [ib_uverbs]
 __x64_sys_ioctl+0x13c/0x1c0
 do_syscall_64+0xba/0x530
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Last potentially related work creation:
 kasan_save_stack+0x20/0x40
 kasan_record_aux_stack+0xb0/0xc0
 __queue_work+0x8c5/0x11f0
 queue_work_on+0x60/0x70
 rxe_sched_task+0x1d2/0x250 [rdma_rxe]
 rxe_rcv+0x847/0x1830 [rdma_rxe]
 rxe_xmit_packet+0x408/0x950 [rdma_rxe]
 rxe_requester+0x1878/0x5460 [rdma_rxe]
 rxe_sender+0x17/0x40 [rdma_rxe]
 do_work+0x149/0x610 [rdma_rxe]
 process_one_work+0x726/0x10a0
 worker_thread+0x500/0xd70
 kthread+0x329/0x410
 ret_from_fork+0x4cf/0x760
 ret_from_fork_asm+0x1a/0x30

The buggy address belongs to the object at ffff88812c486000
 which belongs to the cache kmalloc-part-13-2k of size 2048
The buggy address is located 0 bytes to the right of
 allocated 2040-byte region [ffff88812c486000, ffff88812c4867f8)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88812c480000 pfn:0x12c480
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
page_type: f5(slab)
raw: 0017ffffc0000240 ffff888100059140 ffffea0004499010 ffffea00049a7a10
raw: ffff88812c480000 0000000200080007 00000000f5000000 0000000000000000
head: 0017ffffc0000240 ffff888100059140 ffffea0004499010 ffffea00049a7a10
head: ffff88812c480000 0000000200080007 00000000f5000000 0000000000000000
head: 0017ffffc0000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88812c486680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88812c486700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88812c486780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
                                                                ^
 ffff88812c486800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88812c486880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Re: [PATCH] RDMA/rxe: Use validated num_sge in local buffer

[Zhu Yanjun]

在 2026/9/8 0:35, Nicolas Morey 写道:
> On 2026-09-08 05:07, Zhu Yanjun wrote:
>> 在 2026/9/7 14:44, Nicolas Morey 写道:
>>> On 2026-09-07 23:20, Zhu Yanjun wrote:
>>>> 在 2026/9/7 9:15, Nicolas Morey 写道:
>>>>> For both SRQ and non-SRQ receive paths, the WQE is copied into a local
>>>>> buffer to provide a kernel-owned, validated copy. While calculating the
>>>>> memcpy size from the validated num_sge prevents overflow during the
>>>>> copy, memcpy() itself still copies num_sge from shared memory.
>>>>>
>>>>> A concurrent userspace modification before or during memcpy() leaves
>>>>> an unvalidated num_sge in the local buffer, leading to potential
>>>>> out-of-bounds reads in rxe_resp_check_length() and copy_data().
>>>>>
>>>>
>>>> Hi Nicolas,
>>>>
>>>> Thanks for the patch. The logic makes total sense to prevent the TOCTOU race condition after memcpy.
>>>>
>>>> Just out of curiosity, do you happen to have a reproducer or a POC script that demonstrates this race in practice?
>>>>
>>>> It would be great to know if this can be reliably reproduced or integrated into testing setups (like rdma-core tests, or tools/testing/selftests/rdma) to catch similar double-read issues in the future.
>>>>
>>>
>>> No reproducer or PoC sadly. I haven't tried to make one though.
>>> This got caught by one of our AI tools when checking the backport of CVE-2026-74377.
>>
>> Hi, Nicolas
>>
>> Thanks for sharing this. Could you clarify whether your AI tool detected this purely through static analysis (and provided a suggested fix), or if it actually triggered a runtime bug with a backtrace/calltrace?
>>
>> If you have a calltrace, please share it—that would help a lot in understanding the issue. Also, if this was flagged and fixed by a specific AI tool, adding an Assisted-by: tag (or referencing the tool in the commit description) would be appropriate.
>>
>> Thanks,
>>
>> Zhu Yanjun
>>
> 
> Hi Zhu,
> 
> The tool is a LLM static analyser that simply detected that d6ab440240a0 ("RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path") was a valid patch but did not fix the whole issue. It did not suggest any breaker PoC nor any fix.
> All the rest is human (me) made.
> Does that warrant an Assisted-by tag ?
> It seems sashiko picked the same issue for 22b8fbded65b ("RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe")
> https://sashiko.dev/#/patchset/20260518215040.1598586-1-tristan%40talencesecurity.com
> 
>> If a concurrent userspace thread modifies wqe->dma.num_sge after the
>> bounds check but before the memcpy completes, doesn't this copy the
>> unvalidated value into the kernel heap?
> 
> By tweaking the reproducer from Tristan, I have been able to reproduce it once out of sheer luck I think:

Thanks a lot. Please add the following call trace into the commit log 
and send out a new commit.

Except the above, I am fine with this commit.

Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>

Zhu Yanjun

> ==================================================================
> BUG: KASAN: slab-out-of-bounds in rxe_receiver+0x8109/0x9ec0 [rdma_rxe]
> Read of size 4 at addr ffff88812c4867f8 by task kworker/u9:6/361
> 
> CPU: 0 UID: 0 PID: 361 Comm: kworker/u9:6 Tainted: G            E       7.3.0-rc2-00006-g28924df2a08f #3 PREEMPT(full)  318a88bba3045f81bad31a7694727561b4bd4965
> Tainted: [E]=UNSIGNED_MODULE
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
> Workqueue: rxe_wq do_work [rdma_rxe]
> Call Trace:
>   <TASK>
>   dump_stack_lvl+0x4b/0x70
>   print_report+0x153/0x4b5
>   ? __pfx__raw_spin_lock_irqsave+0x10/0x10
>   ? stack_trace_save+0x93/0xd0
>   kasan_report+0xbc/0xf0
>   ? rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   ? rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   rxe_receiver+0x8109/0x9ec0 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   ? pick_task_fair+0x12e/0x1b50
>   ? __pfx_rxe_receiver+0x10/0x10 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   ? __pfx__raw_spin_lock_irqsave+0x10/0x10
>   ? hrtimer_start_range_ns+0xe7/0x320
>   ? ktime_get+0xe3/0x170
>   ? _raw_spin_unlock+0xe/0x30
>   ? _raw_spin_lock_irqsave+0x8a/0xf0
>   ? __pfx__raw_spin_lock_irqsave+0x10/0x10
>   ? __pfx_rxe_receiver+0x10/0x10 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   do_work+0x149/0x610 [rdma_rxe b8d153a5fa9911e345612beff278ac3241bac327]
>   process_one_work+0x726/0x10a0
>   ? __pfx___schedule+0x10/0x10
>   ? __pfx_process_one_work+0x10/0x10
>   ? _raw_spin_lock_irq+0x85/0xe0
>   ? __pfx__raw_spin_lock_irq+0x10/0x10
>   worker_thread+0x500/0xd70
>   ? __kthread_parkme+0x8d/0x170
>   ? __pfx_worker_thread+0x10/0x10
>   ? __pfx_worker_thread+0x10/0x10
>   kthread+0x329/0x410
>   ? recalc_sigpending+0x15c/0x200
>   ? __pfx_kthread+0x10/0x10
>   ret_from_fork+0x4cf/0x760
>   ? __pfx_ret_from_fork+0x10/0x10
>   ? __switch_to+0x575/0x11c0
>   ? __pfx_kthread+0x10/0x10
>   ret_from_fork_asm+0x1a/0x30
>   </TASK>
> 
> Allocated by task 1698:
>   kasan_save_stack+0x20/0x40
>   kasan_save_track+0x14/0x30
>   __kasan_kmalloc+0x9a/0xb0
>   __kmalloc_noprof+0x209/0x560
>   create_qp.part.0+0x760/0x9d0 [ib_core]
>   ib_create_qp_user+0xa2/0x500 [ib_core]
>   ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x99b/0x12af [ib_uverbs]
>   ib_uverbs_cmd_verbs+0x214b/0x32d0 [ib_uverbs]
>   ib_uverbs_ioctl+0x131/0x200 [ib_uverbs]
>   __x64_sys_ioctl+0x13c/0x1c0
>   do_syscall_64+0xba/0x530
>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Last potentially related work creation:
>   kasan_save_stack+0x20/0x40
>   kasan_record_aux_stack+0xb0/0xc0
>   __queue_work+0x8c5/0x11f0
>   queue_work_on+0x60/0x70
>   rxe_sched_task+0x1d2/0x250 [rdma_rxe]
>   rxe_rcv+0x847/0x1830 [rdma_rxe]
>   rxe_xmit_packet+0x408/0x950 [rdma_rxe]
>   rxe_requester+0x1878/0x5460 [rdma_rxe]
>   rxe_sender+0x17/0x40 [rdma_rxe]
>   do_work+0x149/0x610 [rdma_rxe]
>   process_one_work+0x726/0x10a0
>   worker_thread+0x500/0xd70
>   kthread+0x329/0x410
>   ret_from_fork+0x4cf/0x760
>   ret_from_fork_asm+0x1a/0x30
> 
> The buggy address belongs to the object at ffff88812c486000
>   which belongs to the cache kmalloc-part-13-2k of size 2048
> The buggy address is located 0 bytes to the right of
>   allocated 2040-byte region [ffff88812c486000, ffff88812c4867f8)
> 
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88812c480000 pfn:0x12c480
> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> flags: 0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
> page_type: f5(slab)
> raw: 0017ffffc0000240 ffff888100059140 ffffea0004499010 ffffea00049a7a10
> raw: ffff88812c480000 0000000200080007 00000000f5000000 0000000000000000
> head: 0017ffffc0000240 ffff888100059140 ffffea0004499010 ffffea00049a7a10
> head: ffff88812c480000 0000000200080007 00000000f5000000 0000000000000000
> head: 0017ffffc0000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>   ffff88812c486680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   ffff88812c486700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ffff88812c486780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
>                                                                  ^
>   ffff88812c486800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   ffff88812c486880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================