From: Tom Herbert <firstname.lastname@example.org>
To: Arnd Bergmann <email@example.com>, Jiri Pirko <firstname.lastname@example.org>,
"David S. Miller" <email@example.com>,
Alexander Duyck <firstname.lastname@example.org>,
Tom Herbert <email@example.com>, Jiri Pirko <firstname.lastname@example.org>,
Hadar Hen Zion <email@example.com>,
Gao Feng <firstname.lastname@example.org>,
Amir Vadai <email@example.com>,
Linux Kernel Network Developers <firstname.lastname@example.org>,
Subject: Re: [PATCH] flow_dissector: avoid uninitialized variable access
Date: Sat, 22 Oct 2016 11:20:34 -0700 [thread overview]
Message-ID: <CALx6S35oHmGNw=7taBLxY8ZJHso-b8eRokz3QFA5j_8tW5N8yg@mail.gmail.com> (raw)
On Sat, Oct 22, 2016 at 8:57 AM, Eric Garver <email@example.com> wrote:
> On Sat, Oct 22, 2016 at 12:16:29AM +0200, Arnd Bergmann wrote:
>> On Friday, October 21, 2016 11:05:45 PM CEST Arnd Bergmann wrote:
>> > 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.
>> Found it now myself: if skb_vlan_tag_present(skb), then we don't
>> access 'vlan', otherwise we know it is initialized because
>> eth_type_vlan(proto) has to be true.
>> > 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.
>> I'm still unsure about this one.
> Only skb_flow_dissect_flow_keys_buf() calls this function with skb ==
> NULL. It uses flow_keys_buf_dissector_keys which does not specify
> FLOW_DISSECTOR_KEY_VLAN, so the if statement is false.
> A similar assumption is made for FLOW_DISSECTOR_KEY_ETH_ADDRS higher up.
This is a serious problem. We can't rely on the callers to know which
keys they are allowed to use to avoid crashing the kernel. We should
fix those to check if skb is NULL, add a comment to the head of the
function warning people to never assume skb is non-NULL, and also
maybe add a degenerative check that both data argument and skb are not
>> I also found something else that is suspicious: 'vlan' points
>> to the local _vlan variable, but that has gone out of scope
>> by the time we access the pointer, which doesn't seem safe.
> I see no harm in moving _vlan to the same scope as vlan.
next prev parent reply other threads:[~2016-10-22 18:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 15:55 [PATCH] flow_dissector: avoid uninitialized variable access Arnd Bergmann
2016-10-21 16:31 ` Jiri Pirko
2016-10-21 21:05 ` Arnd Bergmann
2016-10-21 22:16 ` Arnd Bergmann
2016-10-22 15:57 ` Eric Garver
2016-10-22 18:20 ` Tom Herbert [this message]
2016-10-22 20:30 ` [PATCH net-next] flow_dissector: fix vlan tag handling Arnd Bergmann
2016-10-24 8:17 ` Jiri Pirko
2016-10-24 16:00 ` Arnd Bergmann
2016-10-22 1:48 ` [PATCH] flow_dissector: avoid uninitialized variable access Linus Torvalds
2016-10-22 6:55 ` Jiri Pirko
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).