The phy_get_internal_delay function could try to access to an empty
array in the case that the driver is calling phy_get_internal_delay
without defining delay_values and rx-internal-delay-ps or
tx-internal-delay-ps is defined to 0 in the device-tree.
This will lead to "unable to handle kernel NULL pointer dereference at
virtual address 0". To avoid this kernel oops, the test should be delay
>= 0. As there is already delay < 0 test just before, the test could
only be size == 0.

Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the internal delay")
Signed-off-by: Kévin L'hôpital <kevin.lhopital@savoirfairelinux.com>
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
---
 drivers/net/phy/phy_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 3611ea64875e..3ad9bbf65cbe 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2959,7 +2959,7 @@ s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
 	if (delay < 0)
 		return delay;
 
-	if (delay && size == 0)
+	if (size == 0)
 		return delay;
 
 	if (delay < delay_values[0] || delay > delay_values[size - 1]) {
-- 
2.34.1

On Thu, Mar 07, 2024 at 09:52:54AM +0100, Kévin L'hôpital wrote:
> The phy_get_internal_delay function could try to access to an empty
> array in the case that the driver is calling phy_get_internal_delay
> without defining delay_values and rx-internal-delay-ps or
> tx-internal-delay-ps is defined to 0 in the device-tree.
> This will lead to "unable to handle kernel NULL pointer dereference at
> virtual address 0". To avoid this kernel oops, the test should be delay
> >= 0. As there is already delay < 0 test just before, the test could
> only be size == 0.
> 
> Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the internal delay")
> Signed-off-by: Kévin L'hôpital <kevin.lhopital@savoirfairelinux.com>
> Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>

The sign-offs look wrong to me. They indicate the path that the patch is
taking to be merged into mainline. Who is the author of this patch and
who is passing it along? If it's co-development, then there is a specific
tag for that.

For the actual patch itself:

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Thanks!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

----- Le 7 Mar 24, à 10:53, Russell King (Oracle) linux@armlinux.org.uk a écrit :

> On Thu, Mar 07, 2024 at 09:52:54AM +0100, Kévin L'hôpital wrote:
>> The phy_get_internal_delay function could try to access to an empty
>> array in the case that the driver is calling phy_get_internal_delay
>> without defining delay_values and rx-internal-delay-ps or
>> tx-internal-delay-ps is defined to 0 in the device-tree.
>> This will lead to "unable to handle kernel NULL pointer dereference at
>> virtual address 0". To avoid this kernel oops, the test should be delay
>> >= 0. As there is already delay < 0 test just before, the test could
>> only be size == 0.
>> 
>> Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the
>> internal delay")
>> Signed-off-by: Kévin L'hôpital <kevin.lhopital@savoirfairelinux.com>
>> Signed-off-by: Enguerrand de Ribaucourt
>> <enguerrand.de-ribaucourt@savoirfairelinux.com>
> 
> The sign-offs look wrong to me. They indicate the path that the patch is
> taking to be merged into mainline. Who is the author of this patch and
> who is passing it along? If it's co-development, then there is a specific
> tag for that.
> 
> For the actual patch itself:
> 
> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> Thanks!
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

I will send a V2 fixing this, thank you.

Kévin L'hôpital