On 11/22/2022 3:30 PM, ok...@kernel.org wrote:
> From: Sinan Kaya <ok...@kernel.org>
>
> In rte_pmd_tun_probe result of call to rte_vdev_device_name is
> dereferenced here and may be null.
>
> Signed-off-by: Sinan Kaya <ok...@kernel.org>
> ---
> drivers/net/tap/rte_eth_tap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index f2a6c33a19..b99439e4f2 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -2340,6 +2340,9 @@ rte_pmd_tun_probe(struct rte_vdev_device *dev)
> struct rte_eth_dev *eth_dev;
>
> name = rte_vdev_device_name(dev);
> + if (name == NULL)
> + return -1;
> +
> params = rte_vdev_device_args(dev);
> memset(remote_iface, 0, RTE_ETH_NAME_MAX_LEN);
>
Yes, technically 'rte_vdev_device_name()' can return NULL, but call
stack is like this:
`
vdev_probe_all_drivers() //in 'vdev.c'
name = rte_vdev_device_name(dev);
if (vdev_parse(name, &driver))
return -1;
ret = driver->probe(dev); //it is 'rte_pmd_tun_probe()'
`
I assume this is highlighted by a tool but in practice
'rte_vdev_device_name()' should not return NULL, and there are many
other location this check is missing.
Although it doesn't hurt, I think we can skip the check since it is
unnecessary.
