It seems that kernel memory can leak into userspace by a
kmalloc, ethtool_get_strings, then copy_to_user sequence.
Avoid this by using kcalloc to zero fill the copied buffer.
Signed-off-by: Joe Perches <j...@perches.com>
---
stable too...
On Tue, 2015-10-13 at 23:59 -0700, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.kel...@intel.com>
[]
> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
[]
> @@ -206,13 +206,13 @@ static void fm10k_get_stat_strings(struct net_device
> *dev, u8 *data)
> }
>
> for (i = 0; i < interface->hw.mac.max_queues; i++) {
> - sprintf(p, "tx_queue_%u_packets", i);
> + snprintf(p, ETH_GSTRING_LEN, "tx_queue_%u_packets", i);
It seems these need a memset after the snprintf to zero fill
bytes after the string terminating \0 to avoid leaking
contents of any unset bytes.
It'd probably be better to allocate a zeroed buffer instead.
> p += ETH_GSTRING_LEN;
> - sprintf(p, "tx_queue_%u_bytes", i);
> + snprintf(p, ETH_GSTRING_LEN, "tx_queue_%u_bytes", i);
so...
net/core/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b495ab1..29edf74 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1284,7 +1284,7 @@ static int ethtool_get_strings(struct net_device *dev,
void __user *useraddr)
gstrings.len = ret;
- data = kmalloc(gstrings.len * ETH_GSTRING_LEN, GFP_USER);
+ data = kcalloc(gstrings.len, ETH_GSTRING_LEN, GFP_USER);
if (!data)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
