[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180501.141930.969764198768375676.davem@davemloft.net>
Date: Tue, 01 May 2018 14:19:30 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: wang6495@....edu
Cc: kjlu@....edu, f.fainelli@...il.com, andrew@...n.ch,
ecree@...arflare.com, rmk+kernel@...linux.org.uk,
alan.brady@...el.com, stephen@...workplumber.org,
eugenia@...lanox.com, inbark@...lanox.com,
vidya.chowdary@...il.com, ynorov@...iumnetworks.com,
viro@...iv.linux.org.uk, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ethtool: fix a potential missing-check bug
From: Wenwen Wang <wang6495@....edu>
Date: Mon, 30 Apr 2018 12:31:13 -0500
> 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.
>
> This patch simply 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>
Applied, thanks.
Powered by blists - more mailing lists