[patch net-next v2] net: ethtool: fix unheld rtnl lock

Diogo Jahchan Koike posted 1 patch 1 year, 3 months ago
There is a newer version of this series
net/ethtool/pse-pd.c | 3 +++
1 file changed, 3 insertions(+)
[patch net-next v2] net: ethtool: fix unheld rtnl lock
Posted by Diogo Jahchan Koike 1 year, 3 months ago
ethnl_req_get_phydev should be called with rtnl lock held.

Reported-by: syzbot+ec369e6d58e210135f71@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ec369e6d58e210135f71
Fixes: 31748765bed3 ("net: ethtool: pse-pd: Target the command to the requested PHY")
Signed-off-by: Diogo Jahchan Koike <djahchankoike@gmail.com>
---
 net/ethtool/pse-pd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index 507cb21d6bf0..0cd298851ea1 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -227,8 +227,11 @@ ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
 	struct nlattr **tb = info->attrs;
 	struct phy_device *phydev;
 
+	rtnl_lock();
 	phydev = ethnl_req_get_phydev(req_info, tb[ETHTOOL_A_PSE_HEADER],
 				      info->extack);
+	rtnl_unlock();
+
 	if (IS_ERR_OR_NULL(phydev)) {
 		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
 		return -EOPNOTSUPP;
-- 
2.43.0
Re: [patch net-next v2] net: ethtool: fix unheld rtnl lock
Posted by Maxime Chevallier 1 year, 3 months ago
Hi,

Thanks for addressing this. I do have some comments though :

On Mon, 26 Aug 2024 11:06:13 -0300
Diogo Jahchan Koike <djahchankoike@gmail.com> wrote:

> ethnl_req_get_phydev should be called with rtnl lock held.
> 
> Reported-by: syzbot+ec369e6d58e210135f71@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ec369e6d58e210135f71
> Fixes: 31748765bed3 ("net: ethtool: pse-pd: Target the command to the requested PHY")
> Signed-off-by: Diogo Jahchan Koike <djahchankoike@gmail.com>
> ---
>  net/ethtool/pse-pd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
> index 507cb21d6bf0..0cd298851ea1 100644
> --- a/net/ethtool/pse-pd.c
> +++ b/net/ethtool/pse-pd.c
> @@ -227,8 +227,11 @@ ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
>  	struct nlattr **tb = info->attrs;
>  	struct phy_device *phydev;
>  
> +	rtnl_lock();
>  	phydev = ethnl_req_get_phydev(req_info, tb[ETHTOOL_A_PSE_HEADER],
>  				      info->extack);
> +	rtnl_unlock();

RTNL lock must be held until the PHY device is no longer being used, as
it may disappear at any point [1]. RTNL protects against that. The first
iteration of your patch had the right idea, as the lock was released at
the end of the function.

[1] : https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/ethtool/netlink.h#n281

Thanks,

Maxime
Re: [patch net-next v2] net: ethtool: fix unheld rtnl lock
Posted by Diogo Jahchan Koike 1 year, 3 months ago
Hi Maxime

Thanks for the clarification, I missed that. Should I resend my first patch
or should I release the lock before every return (tbh, I feel like that may
lead to a lot of repeated code) and send a new patch?

Thanks,
	Diogo Jahchan Koike
Re: [patch net-next v2] net: ethtool: fix unheld rtnl lock
Posted by Christophe Leroy 1 year, 3 months ago
Hi Diogo,

Le 26/08/2024 à 19:00, Diogo Jahchan Koike a écrit :
> [Vous ne recevez pas souvent de courriers de djahchankoike@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Maxime
> 
> Thanks for the clarification, I missed that. Should I resend my first patch
> or should I release the lock before every return (tbh, I feel like that may
> lead to a lot of repeated code) and send a new patch?
> 

Do not duplicate release lock before every return.

See 
https://docs.kernel.org/process/coding-style.html#centralized-exiting-of-functions

Christophe
Re: [patch net-next v2] net: ethtool: fix unheld rtnl lock
Posted by Diogo Jahchan Koike 1 year, 3 months ago
Hi Cristophe

Yes, thanks for reviewing, I will just resend my first patch that used the out
label now that I am aware that the lock has to be held during all interactions
with the device.

Thanks,
	Diogo Jahchan Koike