[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00aa634b-edc0-220d-47d1-551c73af9f3b@solarflare.com>
Date: Mon, 30 Apr 2018 15:20:55 +0100
From: Edward Cree <ecree@...arflare.com>
To: Wenwen Wang <wang6495@....edu>
CC: Kangjie Lu <kjlu@....edu>, "David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Russell King <rmk+kernel@...linux.org.uk>,
Inbar Karmy <inbark@...lanox.com>,
Eugenia Emantayev <eugenia@...lanox.com>,
Al Viro <viro@...iv.linux.org.uk>,
Yury Norov <ynorov@...iumnetworks.com>,
Vidya Sagar Ravipati <vidya.chowdary@...il.com>,
Alan Brady <alan.brady@...el.com>,
"Stephen Hemminger" <stephen@...workplumber.org>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ethtool: fix a potential missing-check bug
On 30/04/18 02:31, Wenwen Wang wrote:
> In ethtool_get_rxnfc(), the object "info" is firstly copied from
> user-space. If the FLOW_RSS flag is set in the member field flow_type of
> "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
> user-space because FLOW_RSS is newer and has new definition, as mentioned
> in the comment. However, given that the user data resides in user-space, a
> malicious user can race to change the data after the first copy. By doing
> so, the user can inject inconsistent data. For example, in the second
> copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
> In the following execution, "info" will be used in the function
> ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
> information leakage since ops->get_rxnfc() will prepare various types of
> data according to flow_type, and the prepared data will be eventually
> copied to user-space. This inconsistent data may also cause undefined
> behaviors based on how ops->get_rxnfc() is implemented.
I'm not sure there's actually an issue here, since the only purpose of the
FLOW_RSS check is to avoid faulting/trampling user memory when the user
process only has the short version of 'info'.
If userland subsequently removes the FLOW_RSS flag, then all that will
happen is that info_size is larger than it ought to be; that cannot affect
ops->get_rxnfc() since it isn't passed; the op should already be treating
'info' as unsafe/user-controlled.
The only way this could lead to information leakage would be if in the non-
FLOW_RSS case ops->get_rxnfc() was writing things it shouldn't into the
latter part of 'info' and was getting away with it so far as that was
never copied_to_user; that seems improbable to me, but I suppose you might
want to do the check anyway as belt-and-braces security.
(A cleaner approach might be to only copy_from_user() the extra region of
'info', leaving the previously-copied part alone. That way each byte is
only copied_from_user once and thus cannot change.)
-Ed
> This patch re-verifies the flow_type field of "info" after the second copy.
> If the value is not as expected, an error code will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@....edu>
> ---
> net/core/ethtool.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 03416e6..a121034 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
> info_size = sizeof(info);
> if (copy_from_user(&info, useraddr, info_size))
> return -EFAULT;
> + if (!(info.flow_type & FLOW_RSS))
> + return -EINVAL;
> }
>
> if (info.cmd == ETHTOOL_GRXCLSRLALL) {
Powered by blists - more mailing lists