linux-kernel - Re: [PATCH] fix for potential NULL pointer dereference with bare lan743x

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20201030165515.614637a0@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Fri, 30 Oct 2020 17:03:53 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sergej Bauer <sbauer@...ckbox.su>
Cc:     Bryan Whitehead <bryan.whitehead@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix for potential NULL pointer dereference with bare
 lan743x

On Thu, 29 Oct 2020 03:28:45 +0300 Sergej Bauer wrote:
>   This is just a minor fix which prevents a kernel NULL pointer
> dereference when using phy-less lan743x.
> 
> Signed-off-by: Sergej Bauer <sbauer@...ckbox.su>

I take you mean when the device is down netdev->phydev will be NULL?

> diff --git a/drivers/net/ethernet/microchip/lan743x_ethtool.c b/drivers/net/ethernet/microchip/lan743x_ethtool.c
> index dcde496da7fb..354d72d550f2 100644
> --- a/drivers/net/ethernet/microchip/lan743x_ethtool.c
> +++ b/drivers/net/ethernet/microchip/lan743x_ethtool.c
> @@ -793,6 +795,9 @@ static int lan743x_ethtool_set_wol(struct net_device *netdev,
>  {
>  	struct lan743x_adapter *adapter = netdev_priv(netdev);
>  
> +	if (!netdev->phydev)
> +		return -EIO;

Does it make sense to just skip the phy_ethtool_set_wol() call instead?

Also doesn't the wol configuration of the PHY get lost across an
netdev up/down cycle in this driver? Should it be re-applied after phy
is connected back?

>  	adapter->wolopts = 0;
>  	if (wol->wolopts & WAKE_UCAST)
>  		adapter->wolopts |= WAKE_UCAST;