netdev - Re: [PATCH net] ice: fix theoretical out-of-bounds access in ethtool link modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 5 Dec 2023 20:46:28 +0000
From: Simon Horman <horms@...nel.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Michal Schmidt <mschmidt@...hat.com>, netdev@...r.kernel.org,
	intel-wired-lan@...ts.osuosl.org,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Paul Greenwalt <paul.greenwalt@...el.com>,
	Petr Oros <poros@...hat.com>
Subject: Re: [PATCH net] ice: fix theoretical out-of-bounds access in ethtool
 link modes

On Fri, Dec 01, 2023 at 08:33:36AM +0100, Przemek Kitszel wrote:
> On 11/30/23 17:58, Michal Schmidt wrote:
> > To map phy types reported by the hardware to ethtool link mode bits,
> > ice uses two lookup tables (phy_type_low_lkup, phy_type_high_lkup).
> > The "low" table has 64 elements to cover every possible bit the hardware
> > may report, but the "high" table has only 13. If the hardware reports a
> > higher bit in phy_types_high, the driver would access memory beyond the
> > lookup table's end.
> > 
> > Instead of iterating through all 64 bits of phy_types_{low,high}, use
> > the sizes of the respective lookup tables.
> > 
> > Fixes: 9136e1f1e5c3 ("ice: refactor PHY type to ethtool link mode")
> > Signed-off-by: Michal Schmidt <mschmidt@...hat.com>
> > ---
> >   drivers/net/ethernet/intel/ice/ice_ethtool.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > index a34083567e6f..bde9bc74f928 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > @@ -1850,14 +1850,14 @@ ice_phy_type_to_ethtool(struct net_device *netdev,
> >   	linkmode_zero(ks->link_modes.supported);
> >   	linkmode_zero(ks->link_modes.advertising);
> > -	for (i = 0; i < BITS_PER_TYPE(u64); i++) {
> > +	for (i = 0; i < ARRAY_SIZE(phy_type_low_lkup); i++) {
> >   		if (phy_types_low & BIT_ULL(i))
> >   			ice_linkmode_set_bit(&phy_type_low_lkup[i], ks,
> >   					     req_speeds, advert_phy_type_lo,
> >   					     i);
> >   	}
> > -	for (i = 0; i < BITS_PER_TYPE(u64); i++) {
> > +	for (i = 0; i < ARRAY_SIZE(phy_type_high_lkup); i++) {
> >   		if (phy_types_high & BIT_ULL(i))
> >   			ice_linkmode_set_bit(&phy_type_high_lkup[i], ks,
> >   					     req_speeds, advert_phy_type_hi,
> 
> I guess that that "HW reported" number really goes through the FW in
> some way, so one could indeed spoil that in some way,
> what makes sense to target it at -net.
> 
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>

Reviewed-by: Simon Horman <horms@...nel.org>