Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Coverity CID: 220541] Dereference before null check in subsys/net/lib/capture/capture.c #34000

Closed
zephyrbot opened this issue Apr 3, 2021 · 6 comments · Fixed by #34037
Closed
Assignees
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug Coverity A Coverity detected issue or its fix priority: low Low impact/importance bug

Comments

@zephyrbot
Copy link
Collaborator

Static code scan issues found in file:

https://github.com/zephyrproject-rtos/zephyr/tree/b86f7addae05add0db45d9b528854235fbb93a48/subsys/net/lib/capture/capture.c#L342

Category: Null pointer dereferences
Function: net_capture_setup
Component: Networking
CID: 220541

Details:

if (remote_iface == NULL) {

336         } else {
337             NET_ERR("Invalid address family %d", remote.sa_family);
338             ret = -EINVAL;
339             goto fail;
340         }
341    
>>>     CID 220541:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "remote_iface" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
342         if (remote_iface == NULL) {
343             NET_ERR("Remote address %s unreachable", remote_addr);
344             ret = -ENETUNREACH;
345             goto fail;
346         }
347    

Please fix or provide comments in coverity using the link:

https://scan9.coverity.com/reports.htm#v29271/p12996

Note: This issue was created automatically. Priority was set based on classification
of the file affected and the impact field in coverity. Assignees were set using the CODEOWNERS file.

@zephyrbot zephyrbot added bug The issue is a bug, or the PR is fixing a bug Coverity A Coverity detected issue or its fix priority: low Low impact/importance bug labels Apr 3, 2021
jukkar added a commit to jukkar/zephyr that referenced this issue Apr 6, 2021
Do not try to set or get the interface MTU if the interface
pointer is NULL.

Coverity-CID: 220541
Fixes zephyrproject-rtos#34000

Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
@mniestroj
Copy link
Member

I think that there should be if (!remote_iface) check added just after remote_iface assignment:

		iremote_iface = net_if_ipv6_select_src_iface(
						&net_sin6(&remote)->sin6_addr);
		if (!remote_iface) {
			NET_ERR("Remote address %s unreachable", remote_addr);
			return -ENETUNREACH;
		}

and

		remote_iface = net_if_ipv4_select_src_iface(
						&net_sin(&remote)->sin_addr);
		if (!remote_iface) {
			NET_ERR("Remote address %s unreachable", remote_addr);
			return -ENETUNREACH;
		}
`
``

@jukkar
Copy link
Member

jukkar commented Apr 7, 2021

I considered that solution but decided to do it differently. If both IPv4 and IPv6 are enabled, there would be the same check twice which is unnecessary. So I placed the remote_iface NULL check after the IPv4/IPv6 checks.

@mniestroj
Copy link
Member

mniestroj commented Apr 7, 2021

There would be two checks in compiled binary, yes. But it is hard to do without it before using net_if_get_mtu(). And I don't think returning 0 from net_if_get_mtu(NULL) (as proposed in jukkar@83db5ca) is a good idea. With this code:

		orig_mtu = net_if_get_mtu(remote_iface);
		mtu = orig_mtu - sizeof(struct net_ipv6_hdr) -
			sizeof(struct net_udp_hdr);

mtu will end up being negative value. In most cases (including that one) returning 0 from NULL interface won't be much of an improvement, so I would rather keep net_if_get_mtu(NULL) behavior undefined, as NULL should not be used in the first place.

@mniestroj
Copy link
Member

If both IPv4 and IPv6 are enabled, there would be the same check twice which is unnecessary

And as noted above, this check would be twice in compiled binary. However for a single function invocation, there would be just a single check.

@mniestroj
Copy link
Member

What about calculating ip headers first (based on IPv4 vs IPv6):

	ip_headers_len = sizeof(struct net_ipv6_hdr);

or

	ip_headers_len = sizeof(struct net_ipv4_hdr);

and then mtu after remote_iface check:

	if (remote_iface == NULL) {
		NET_ERR("Remote address %s unreachable", remote_addr);
		ret = -ENETUNREACH;
		goto fail;
	}

	mtu = net_if_get_mtu(remote_iface) - ip_headers_len -
		sizeof(struct net_udp_hdr);

@jukkar
Copy link
Member

jukkar commented Apr 7, 2021

mtu will end up being negative value.

The mtu value (if <0) is not used as we bail out if remote_iface is NULL.

nashif pushed a commit that referenced this issue Apr 20, 2021
Do not try to set or get the interface MTU if the interface
pointer is NULL.

Coverity-CID: 220541
Fixes #34000

Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug Coverity A Coverity detected issue or its fix priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants