Thread (11 messages) flat view 11 messages, 5 authors, 2016-10-24

Re: [PATCH] flow_dissector: avoid uninitialized variable access

From: Arnd Bergmann <arnd@arndb.de>
Date: 2016-10-21 21:06:10
Also in: lkml

On Friday, October 21, 2016 6:31:18 PM CEST Jiri Pirko wrote:
Fri, Oct 21, 2016 at 05:55:53PM CEST, arnd@arndb.de wrote:
quoted
gcc warns about an uninitialized pointer dereference in the vlan
priority handling:

net/core/flow_dissector.c: In function '__skb_flow_dissect':
net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]

From all I can tell, this warning is about a real bug, and we
should not attempt look up the vlan header if there was
no vlan tag.
I don't see how vlan could be used uninitialized. But I understand that
this is impossible for gcc to track it. Please just use uninitialized_var()
I usually try to avoid uninitialized_var(), as making it obvious to
the compiler why something is known tends to result in more readable
source code and better object code.

Can you explain why "dissector_uses_key(flow_dissector,
FLOW_DISSECTOR_KEY_VLAN) && skb_vlan_tag_present(skb)" implies
"eth_type_vlan(proto))"?

If I add uninitialized_var() here, I would at least put that in
a comment here.

On a related note, I also don't see how
"dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_VLAN)"
implies that skb is non-NULL. I guess this is related to the
first one.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help