Re: [PATCH] RDMA/iwpm: fix memory leak in iwpm_add_remote_info()

[sashiko-bot@kernel.org]

> NETLINK_RDMA accepts requests addressed to kernel port ID 0 from a local
> unprivileged socket. The IWCM RDMA_NL_IWPM_REMOTE_INFO callback has no
> RDMA_NL_ADMIN_PERM flag, and RDMA netlink routes this IWCM opcode to its
> dump callback even without NLM_F_DUMP.
> 
> iwpm_remote_info_cb() parses the six required attributes and only checks
> that the local and mapped-local sockaddr_storage families match and that
> the remote and mapped-remote families match. Four family-255 addresses
> pass those checks. The callback allocates an iwpm_remote_info object
> with GFP_ATOMIC and passes it to iwpm_add_remote_info(). There,
> get_reminfo_hash_bucket() accepts only AF_INET and AF_INET6, so the
> family-255 lookup returns NULL. The object is neither linked into
> iwpm_reminfo_bucket nor freed, and the callback returns -EINVAL after
> this allocation side effect.
> 
> iwpm_exit() only walks and frees linked hash entries, so closing the
> netlink socket does not recover these orphaned objects. As a result, an
> unprivileged local user in the initial network namespace can repeatedly
> send this request without CAP_NET_ADMIN to permanently leak unreclaimable
> kernel slab memory (kmalloc-512), leading to memory exhaustion and a
> denial of service (DoS).
> 
> Initialize hash_bucket_head to NULL and, after the spinlock is released,
> free rem_info if no bucket accepted it. Freeing after unlock also covers
> the absent-table case without changing the protected list operation and
> follows the existing null-bucket cleanup pattern in iwpm_add_mapinfo().
> 
> Fixes: 6eec17746175 ("RDMA/core: Enable the iWarp Port Mapper to provide the actual address of the connecting peer to its clients")
> Signed-off-by: Junyoung Jang <graypanda.inzag@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109200330.2361828-1-graypanda.inzag@gmail.com?part=1