Question about the relevance of "Fix memory corruption in CM" patchset to syzkaller bugs found on stable 5.10

Question about the relevance of "Fix memory corruption in CM" patchset to syzkaller bugs found on stable 5.10

[Chen Zhen]

Hi everyone,

I am reaching out to consult on two recent syzkaller issues found in the ib/cm module on stable 5.10.
Both issues occur when ib_cancel_mad interacts with cm_id_priv->av.port data.

I noticed the following patchset from Leon:
Fix memory corruption in CM, Link:https://lore.kernel.org/all/cover.1622629024.git.leonro@nvidia.com/
The description of that patchset mentions fixing memory corruption.

I would like to ask:
Is this specific patchset intended to cover the null-ptr-deref and UAF scenarios described below?
If not, is there any other known work regarding these lifetime issues in the CM module?

----------------------------------
Issue 1: null-ptr-deref in ib_modify_mad
This appears to be caused by cm_port->mad_agent being NULL
when ib_cancel_mad attempts to access it

BUG: KASAN: null-ptr-deref in ib_modify_mad+0xe8/0x580
Write of size 4 at addr 0000000000000060 by task syz.7.3487/15508

CPU: 2 PID: 15508 Comm: syz.7.3487 Tainted: G        W         5.10.0-xxxxx #1
Call traqmp_cmd_name: human-monitor-command, arguments: {"command-line": "info registers", "cpu-index": 1}
 dump_backtrace+0x0/0qmp_cmd_name: human-monitor-command, arguments: {"command-line": "info registers", "cpu-index": 2}
 show_stack+0x34/0x44qmp_cmd_name: human-monitor-command, arguments: {"command-line": "info registers", "cpu-index": 3}
 dump_stack+0x1d0/0x248
 __kasan_report+0x138/0x140
 kasan_report+0x44/0x5c
 check_memory_region+0xf8/0x1a0
 __kasan_check_write+0x20/0x30
 ib_modify_mad+0xe8/0x580
 ib_cancel_mad+0x34/0x44
 cm_destroy_id+0xd68/0xfec
 ib_destroy_cm_id+0x2c/0x40
 _destroy_id+0xb4/0x4a4
 destroy_id_handler_unlock+0x194/0x2cc
 rdma_destroy_id+0x30/0x40
 ucma_destroy_private_ctx+0x28c/0x2ac
 ucma_close+0x1a0/0x290
 __fput+0x168/0x5a0

----------------------------------
Issue 2: KASAN: use-after-free in cm_destroy_id
it seems cm_port has freed when ib_cancel_mad path in cm_destroy_id

BUG: KASAN: use-after-free in cm_destroy_id+0x2d4/0xfec
Read of size 8 at addr ffff3ec5e9f1e808 by task syz.8.3746/16234

CPU: 3 PID: 16234 Comm: syz.8.3746 Tainted: G        W         5.10.0-xxxxx #1
Hardware name: QEMU KVM Virtual Maqmp_cmd_name: qmp_capabilities, arguments: {}
Call traceqmp_cmd_name: human-monitor-command, arguments: {"command-line": "info registers", "cpu-index": 0}
 dump_backtrace+0x0/0x4a0
 print_qmp_cmd_name: human-monitor-command, arguments: {"command-line": "info registers", "cpu-index": 3}
 __kasan_report+0xe0/0x140
 kasan_report+0x44/0x5c
 __asan_load8+0xac/0xd0
 cm_destroy_id+0x2d4/0xfec
 ib_destroy_cm_id+0x2c/0x40
 _destroy_id+0xb4/0x4a4
 destroy_id_handler_unlock+0x194/0x2cc
 rdma_destroy_id+0x30/0x40
 ucma_destroy_private_ctx+0x28c/0x2ac
 ucma_close+0x1a0/0x290
 __fput+0x168/0x5a0
 ____fput+0x28/0x40
 task_work_run+0x1f8/0x360
 do_notify_resume+0x3d8/0x3e0
 work_pending+0xc/0x5e4

Allocated by task 6691:
 kasan_save_stack+0x28/0x60
 __kasan_kmalloc.constprop.0+0xa4/0xd0
 kasan_kmalloc+0x10/0x20
 kmem_cache_alloc_trace+0xb4/0x590
 cm_add_one+0x264/0x86c  // alloc cm_port
 add_client_context+0x3bc/0x4c0
 enable_device_and_get+0x178/0x300
 ib_register_device.part.0+0x11c/0x284
 ib_register_device+0x5c/0x7c
 rxe_register_device+0x1c4/0x280
 rxe_add+0x144/0x20c
 rxe_net_add+0x58/0xc0
 rxe_newlink+0xb0/0x100
 nldev_newlink+0x274/0x424
 rdma_nl_rcv_msg+0x244/0x3a0
 rdma_nl_rcv_skb.constprop.0.isra.0+0x220/0x2f4
 rdma_nl_rcv+0x28/0x3c
 netlink_unicast_kernel+0x124/0x290
 netlink_unicast+0x220/0x32c
 netlink_sendmsg+0x4a8/0x8bc
 __sock_sendmsg+0x90/0xd0
 ____sys_sendmsg+0x534/0x60c
 ___sys_sendmsg+0x10c/0x174
 __sys_sendmsg+0xfc/0x1a4
 __arm64_sys_sendmsg+0x58/0x6c
 invoke_syscall+0x70/0x130
 el0_svc_common.constprop.0+0x29c/0x2ac
 do_el0_svc+0x50/0x12c
 el0_svc+0x24/0x34
 el0_sync_handler+0x180/0x18c
 fast_work_pending464+0x178/0x18c

Freed by task 563:
 kasan_save_stack+0x28/0x60
 kasan_set_track+0x28/0x40
 kasan_set_free_info+0x28/0x50
 __kasan_slab_free+0x100/0x190
 kasan_slab_free+0x14/0x20
 kfree+0xac/0x680
 cm_remove_one+0x620/0x88c  //
 remove_client_context+0xc4/0x130
 disable_device+0x12c/0x240
 __ib_unregister_device+0x88/0x140
 ib_unregister_work+0x28/0x40
 process_one_work+0x468/0xabc
 worker_thread+0x120/0x810
 kthread+0x1b8/0x204
 ret_from_fork+0x10/0x18
----------------------------------

Any insights or suggestions would be greatly appreciated.

Best regards,
Chen Zhen

Re: Question about the relevance of "Fix memory corruption in CM" patchset to syzkaller bugs found on stable 5.10

[Leon Romanovsky]

On Wed, Jan 07, 2026 at 05:22:55PM +0800, Chen Zhen wrote:
> Hi everyone,
> 
> I am reaching out to consult on two recent syzkaller issues found in the ib/cm module on stable 5.10.
> Both issues occur when ib_cancel_mad interacts with cm_id_priv->av.port data.
> 
> I noticed the following patchset from Leon:
> Fix memory corruption in CM, Link:https://lore.kernel.org/all/cover.1622629024.git.leonro@nvidia.com/
> The description of that patchset mentions fixing memory corruption.
> 
> I would like to ask:
> Is this specific patchset intended to cover the null-ptr-deref and UAF scenarios described below?

It looks like that work should address your MAD issues.

> If not, is there any other known work regarding these lifetime issues in the CM module?

I'm not aware of any.

Thanks