Coverity issue fixes

There is a potential issue seen by static tools if number of multicast addresses is zero, and rte_realloc of zero size fails (ie returns NULL). This won't happen in real world for a couple of reasons: Azure doesn't support multicast (ie this is dead code);

and rte_realloc of zero size
will never fail, but safe to just always return -ENOMEM of realloc fails.

Coverity issue: 323487

Fixes 901efc0da925 ("net/failsafe: support multicast address list set")

Signed-off-by Stephen Hemminger <[email protected]>

---
  drivers/net/failsafe/failsafe_ops.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/failsafe/failsafe_ops.c +1 -1

index 7f8bcd4c69f4..a20953a662e1 100644
@@ -1155,7 +1155,7 @@ fs_set_mc_addr_list(struct rte_eth_dev *dev,
 
  	mcast_addrs = rte_realloc(PRIV(dev)->mcast_addrs,
  		nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]), 0);
-	if (mcast_addrs == NULL && nb_mc_addr > 0) {
+	if (mcast_addrs == NULL) {
  		ret = -ENOMEM;
  		goto rollback;
  	}

Quoted 4 lines · Stephen Hemminger

There is a potential issue seen by static tools if number of multicast addresses is zero, and rte_realloc of zero size fails (ie returns NULL). This won't happen in real world for a couple of reasons: Azure doesn't support multicast (ie this is dead code);

Is it guaranteed that Azure is the only user of the code? Sorry, it does not sound like an argument at all.

Quoted 3 lines

and rte_realloc of zero size
will never fail, but safe to just always return -ENOMEM of realloc fails.

It is false statement. If ptr is NULL, rte_malloc() is used which explicitly returns NULL if size is 0.

Quoted 1 line

Coverity issue: 323487

It is 100% false alarm from Coverity. rte_memcpy() does nothing if size is 0 and it is zero if number of addresses is zero. If we really want to cope with it (I'm not sure), just do rte_memcpy() in else branch. And it should explained in the comment that it is required to address false issue from static analysis tool only.

Other option is to add check for dummy set (zero number of addresses when it is already zero, but it is extra lines of code and extra logic which is not actually required here. So, more harm from my point of view.

Any solution is fine because of that. You could flag it as false in Coverity or change code to avoid warning. Just want to get it fixed, don't care how.

If netlink socket setup fails the file descriptor was leaked.

Coverity issue: 257040

Fixes 7c25284e30c2 ("net/tap: add netlink back-end for flow API")

Signed-off-by Stephen Hemminger <[email protected]>

---
drivers/net/tap/tap_netlink.c | 3 +++

1 file changed, 3 insertions(+)

drivers/net/tap/tap_netlink.c +3 -0

index 6cb510092218..14bbbec754f6 100644
@@ -51,14 +51,17 @@ tap_nl_init(uint32_t nl_groups)
 	}
 	if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &sndbuf_size, sizeof(int))) {
 		TAP_LOG(ERR, "Unable to set socket buffer send size");
+		close(fd);
 		return -1;
 	}
 	if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvbuf_size, sizeof(int))) {
 		TAP_LOG(ERR, "Unable to set socket buffer receive size");
+		close(fd);
 		return -1;
 	}
 	if (bind(fd, (struct sockaddr *)&local, sizeof(local)) < 0) {
 		TAP_LOG(ERR, "Unable to bind to the netlink socket");
+		close(fd);
 		return -1;
 	}
 	return fd;

Signature · 1 line

2.17.1

Static analysis tools don't like the fact that fd could be zero in the error path. This won't happen in real world because stdin would have to be closed, then other error occurring.

Coverity issue: 14079

Fixes 02f96a0a82d1 ("net/tap: add TUN/TAP device PMD")

Signed-off-by Stephen Hemminger <[email protected]>

---
drivers/net/tap/rte_eth_tap.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/tap/rte_eth_tap.c +0 -0

index 84aaf241019a..f7087222b319 100644
@@ -231,7 +231,7 @@ tun_alloc(struct pmd_internals *pmd, int is_keepalive)
 	return fd;
 

error:

drivers/net/tap/rte_eth_tap.c +1 -1

-	if (fd > 0)
+	if (fd >= 0)

		close(fd);
	return -1;
}

Signature · 1 line

2.17.1

These are all error path issues and should not matter in a real application; most of the error are impossible to cause and applications just fail if setup fails.

Stephen Hemminger (4):
net/failsafe: avoid rte_memcpy if rte_realloc fails bus/vmbus: fix directory handle leak on error net/tap: fix file descriptor leak on error net/tap: fix warning about comparison of fd