Re: [PATCH v1] RDMA/iwpm: Fix use-after-free in mapping info dump

[Leon Romanovsky <leon@kernel.org>]

On Mon, Nov 02, 2026 at 04:18:13PM +0800, Binbin Deng wrote:
> iwpm_send_mapinfo() walks the mapinfo hash table while holding
> iwpm_mapinfo_lock, but when the current skb is full it temporarily drops
> that lock to send the skb and allocate another one.  The hlist iterator is
> not protected across that window:
> 
> CPU0                                                CPU1
> iwpm_send_mapinfo()
> spin_lock_irqsave(&iwpm_mapinfo_lock, flags)
> hlist_for_each_entry(..., map_info, ...)
>   map_info points at map_info A
>   fill the current skb
>   spin_unlock_irqrestore(&iwpm_mapinfo_lock,flags)
>   send the skb / allocate the next skb
>                                                     iwpm_remove_mapinfo()
>                                                     spin_lock_irqsave(&iwpm_mapinfo_lock,flags)
>                                                     find map_info A
>                                                     hlist_del_init(&A->hlist_node)
>                                                     kfree(A)
>                                                     spin_unlock_irqrestore(&iwpm_mapinfo_lock, flags)
> spin_lock_irqsave(&iwpm_mapinfo_lock, flags)
> hlist_for_each_entry() reads A->hlist_node.next
> 
> CPU0 then resumes an iterator whose object has been freed, producing a
> use-after-free.  The race is reachable with many mapped iWARP CM IDs when
> the port mapper hello path dumps the mapinfo table concurrently with
> teardown of the ID at the iterator position.  It can be reported by KASAN
> or lead to memory corruption and a panic.
> 
> The spinlock still protects the hash table itself, but it cannot protect
> an iterator that is retained across an unlock.  Add a mutex which covers
> the complete dump and also serializes individual removal and full-table
> cleanup.  The netlink dump and CM ID teardown paths can sleep, so this
> outer lock is appropriate.
> 
> Found during a static-analysis-assisted audit: candidate sites were
> surfaced by a Coccinelle rule, and the reader/writer paths were
> confirmed by deep code inspection. Due to a lack of hardware
> infrastructure, the issue was not observed at runtime.

Sorry, but we should not add locks to legacy code without thorough testing.

Thanks