Re: [PATCH rdma-next v2 11/14] RDMA/core: Make device names unique per net namespace

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Format String Vulnerability / Arbitrary Memory Write
--

--- Patch [11]: [PATCH rdma-next v2 11/14] RDMA/core: Make device names unique per net namespace ---
commit db3597c8065e66f96858593e01ba04bca7a7d075
Author: Jiri Pirko <jiri@nvidia.com>

RDMA/core: Make device names unique per net namespace

This commit updates RDMA device name lookups and index allocations to be
scoped within the relevant net namespace. It uses rdma_dev_access_netns()
to ensure name uniqueness per namespace while maintaining system-wide
behavior in shared mode.

> diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
> --- a/drivers/infiniband/core/device.c
> +++ b/drivers/infiniband/core/device.c

[ ... ]

> @@ -452,7 +457,7 @@ static int __alloc_name_id(struct net *net, const char *name,
>  	xa_for_each (&devices, index, device) {
>  		char buf[IB_DEVICE_NAME_MAX];
>  
> -		if (device == skip)
> +		if (device == skip || !rdma_dev_access_netns(device, net))
>  			continue;
>  		if (sscanf(dev_name(&device->dev), name, &i) != 1)
>  			continue;

[Severity: Critical]
This isn't a bug introduced by this patch, but is it possible that the
sscanf call here is vulnerable to a format string injection?

Since name can be user-supplied via the RDMA_NLDEV_CMD_NEWDEV netlink
command in nldev_newdev() and is copied without checking for '%' characters:

drivers/infiniband/core/nldev.c:nldev_newdev() {
        ...
        nla_strscpy(name, tb[RDMA_NLDEV_ATTR_DEV_NAME], sizeof(name));
        ...
}

The string is passed down through ib_register_device() and assign_name()
into __alloc_name_id(). Could a user with CAP_NET_ADMIN supply a malicious
format string containing format specifiers like %n?

If an attacker sets up a device with a matching prefix, sscanf would
parse the attacker's format string and write to memory addresses beyond
the supplied &i pointer.

Since CAP_NET_ADMIN can be acquired within a user namespace, could this
allow unprivileged local attackers to corrupt memory and trigger an
arbitrary memory write?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714142927.1298897-1-jiri@resnulli.us?part=11