[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220429233049.3726791-1-colin.foster@in-advantage.com>
Date: Fri, 29 Apr 2022 16:30:47 -0700
From: Colin Foster <colin.foster@...advantage.com>
To: linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc: Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>, UNGLinuxDriver@...rochip.com,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Vladimir Oltean <vladimir.oltean@....com>
Subject: [PATCH v1 net 0/2] fix shared vcap_props reference
Felix vcap_props get statically allocated at the file scope, while the
felix / ocelot instances get dynamically allocated at initialization. If
there's more than one instance, each instance will be writing over the
same vcap_props memory region, which would lead to corruption.
I don't have any hardware to confidently test the vcap portions of
Ocelot / Felix, so any testers would be appreciated.
Also, I believe the memcpy of a structure array should be
architecture-portable, but I'm not 100% confident there, so that might
be an area of extra scrutiny.
Colin Foster (2):
net: ethernet: ocelot: rename vcap_props to clearly be an ocelot
member
net: mscc: ocelot: fix possible memory conflict for vcap_props
drivers/net/dsa/ocelot/felix.c | 3 +-
drivers/net/dsa/ocelot/felix.h | 2 +-
drivers/net/dsa/ocelot/felix_vsc9959.c | 2 +-
drivers/net/dsa/ocelot/seville_vsc9953.c | 2 +-
drivers/net/ethernet/mscc/ocelot_flower.c | 4 +-
drivers/net/ethernet/mscc/ocelot_vcap.c | 54 +++++++++++-----------
drivers/net/ethernet/mscc/ocelot_vsc7514.c | 5 +-
include/soc/mscc/ocelot.h | 34 +++++++++++++-
include/soc/mscc/ocelot_vcap.h | 32 -------------
9 files changed, 71 insertions(+), 67 deletions(-)
--
2.25.1
Powered by blists - more mailing lists