All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tariq Toukan" <tariqt@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next 09/10] net: devmem: add netdev_has_dmabuf_binding() helper
Date: Fri, 09 Oct 2026 13:31:06 +0000	[thread overview]
Message-ID: <sashiko-outbox-165643@kernel.org> (raw)
In-Reply-To: <20261008132815.654147-10-tariqt@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: UAF in netdev_nl_sock_priv_destroy() via dangling TX dmabuf binding
--

commit 40bdbb4bbbf641843a6898fd459c6b04de1f14f3
Author: Dragos Tatulea <dtatulea@nvidia.com>

net: devmem: add netdev_has_dmabuf_binding() helper

Currently there is no way to check whether a dmabuf is bound on a TX queue.
To help with that, add a helper to check whether a devmem dmabuf binding may
still be in use on a given netdev. A new list is introduced to track bindings
for their whole lifetime.

> diff --git a/net/core/devmem.c b/net/core/devmem.c
> index 07c62e2e3088c..173d66d1cb6e2 100644
> --- a/net/core/devmem.c
> +++ b/net/core/devmem.c
[ ... ]
> @@ -357,6 +368,25 @@ struct net_devmem_dmabuf_binding *net_devmem_lookup_dmabuf(u32 id)
>  	return binding;
>  }
>  
> +bool netdev_has_dmabuf_binding(struct net_device *dev, struct device *dma_dev)
> +{
> +	struct net_devmem_dmabuf_binding *binding;
> +	bool found = false;
> +
> +	spin_lock(&net_devmem_live_bindings_lock);
> +	list_for_each_entry(binding, &net_devmem_live_bindings, live_list) {
> +		if (dev == READ_ONCE(binding->dev) &&

[Severity: High]
Can this lead to false positive matches and a use-after-free if the underlying
net_device is freed?

Looking at the lifecycle of TX dmabuf bindings, binding->dev is cached during
net_devmem_bind_dmabuf() without holding a reference. However, there is no
unregister hook to clear binding->dev for TX bindings when the device is
unregistered.

If a user creates a TX binding on a virtual network device, unregisters the
device, but keeps the netlink socket open, binding->dev becomes a dangling
pointer.

If the slab allocator reuses this freed memory address for a new device, won't
this dev == READ_ONCE(binding->dev) check match the wrong device and return a
false positive?

Additionally, when the netlink socket is eventually closed,
netdev_nl_sock_priv_destroy() will iterate over the socket's bindings and
attempt to hold a reference to the device:

netdev_nl_sock_priv_destroy()
    ...
    netdev_hold(dev, &dev_tracker, GFP_KERNEL);

Will this result in a use-after-free on the freed device memory?

> +		    (!dma_dev || binding->attachment->dev == dma_dev)) {
> +			found = true;
> +			break;
> +		}
> +	}
> +	spin_unlock(&net_devmem_live_bindings_lock);
> +
> +	return found;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008132815.654147-1-tariqt@nvidia.com?part=9

  reply	other threads:[~2026-10-09 13:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 13:28 [PATCH net-next 00/10] net/mlx5e: Add netdev support for data direct Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 01/10] net/mlx5: Log the data direct to PF device mapping Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-08 13:28 ` [PATCH net-next 02/10] net/mlx5e: Register supported netdevs as data direct users Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-08 13:28 ` [PATCH net-next 03/10] net/mlx5e: Pre-calculate UMR padding and entry size Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-08 13:28 ` [PATCH net-next 04/10] net/mlx5e: Add data direct ethtool private flag Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-08 13:28 ` [PATCH net-next 05/10] net/mlx5e: Add data direct RX infrastructure Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-10 13:27     ` Dragos Tatulea
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 06/10] net/mlx5e: Add data direct TX infrastructure Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-10 13:45     ` Dragos Tatulea
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 07/10] net/mlx5e: Use the correct DMA dev when data_direct pdev enabled Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 08/10] net/mlx5e: Recreate netdev channels on data direct device unbind Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-10 13:47     ` Dragos Tatulea
2026-10-09 23:56   ` Mina Almasry
2026-10-10 14:00     ` Dragos Tatulea
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 09/10] net: devmem: add netdev_has_dmabuf_binding() helper Tariq Toukan
2026-10-09 13:31   ` sashiko-bot [this message]
2026-10-09 23:56   ` Mina Almasry
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 10/10] net/mlx5e: Enable the data direct netdev feature Tariq Toukan
2026-10-09 13:31   ` sashiko-bot
2026-10-10 13:55     ` Dragos Tatulea
2026-10-09 23:56   ` Mina Almasry
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-09 16:42 ` [PATCH net-next 00/10] net/mlx5e: Add netdev support for data direct Mina Almasry
2026-10-09 23:54   ` Mina Almasry
2026-10-10 14:16     ` Dragos Tatulea
2026-10-11 16:25       ` Mina Almasry
2026-10-11 18:54         ` Dragos Tatulea
2026-10-11 13:54     ` Tariq Toukan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-165643@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.