From: sashiko-bot@kernel.org
To: "Christian Marangi" <ansuelsmth@gmail.com>, devicetree@vger.kernel.org
Cc: robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH net-next v20 08/15] net: phylink: support PCS provider release
Date: Sun, 15 Nov 2026 10:45:16 +0000 [thread overview]
Message-ID: <sashiko-outbox-215399@kernel.org> (raw)
In-Reply-To: <20261114104426.235620-9-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found 7 potential
issues to consider:
- [Medium] net: phylink: unchecked validation in
phylink_calculate_capabilities()
- [Medium] net: phylink: pcs_provider_notify() clobbers mode and media
linkmodes
- [Medium] net: phylink: duplicate phylink_pcs_disable() in
phylink_del_pcs()
- [Medium] net: phylink: force_major_config in phylink_del_pcs() runs
when disabled
- [Medium] net: phylink: race in phylink_create() after registering
fwnode_pcs_nb
- [Medium] net: phylink: missing !pcs check in
phylink_validate_mac_and_pcs()
- [Medium] net: phylink: UAF of phylink_pcs in phylink_destroy() and
phylink_create()
--
commit 9f425957f6e59d4881b3a8c251eeacc60b88a666
Author: Christian Marangi <ansuelsmth@gmail.com>
net: phylink: support PCS provider release
This commit adds a blocking notifier chain for fwnode PCS provider
removal so phylink instances can detach removed PCS instances, refresh
supported interfaces and capabilities, and trigger link resolution.
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 46b2aba336bd1..e807fcccb5de9 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
[ ... ]
> @@ -722,6 +725,8 @@ static void phylink_calculate_capabilities(struct phylink *pl)
> {
> __ETHTOOL_DECLARE_LINK_MODE_MASK(disabled_advertising);
>
> + lockdep_assert_held(&pl->state_mutex);
> +
> /* Get user-disabled advertising modes */
> linkmode_xor(disabled_advertising, pl->advertising,
> pl->link_config.advertising);
> @@ -729,7 +734,7 @@ static void phylink_calculate_capabilities(struct phylink *pl)
> /* Calculate the full supported advertisement */
> linkmode_fill(pl->supported);
> linkmode_copy(pl->link_config.advertising, pl->supported);
> - phylink_validate(pl, pl->supported, &pl->link_config);
> + __phylink_validate(pl, pl->supported, &pl->link_config);
[Severity: Medium]
Does phylink_calculate_capabilities() leave pl->supported and
pl->advertising filled with all ones when __phylink_validate() fails?
When pcs_provider_notify() removes the PCS that provided
pl->link_config.interface and rebuilds pl->supported_interfaces,
pl->link_config.interface still holds the removed interface mode.
__phylink_validate() then returns -EINVAL at the test_bit() check before
clearing or masking pl->supported or pl->link_config.advertising:
drivers/net/phy/phylink.c:__phylink_validate() {
...
if (!test_bit(state->interface, interfaces))
return -EINVAL;
}
Because the return value is ignored after linkmode_fill(pl->supported),
every ethtool linkmode bit remains set in pl->supported, pl->advertising,
and (except for previously disabled bits) pl->link_config.advertising.
[ ... ]
> @@ -2066,11 +2084,91 @@ static int phylink_fill_available_pcs(struct phylink *pl,
> }
>
> out:
> + mutex_unlock(&pl->state_mutex);
> +
> kfree(pcss);
>
> return ret;
> }
>
> +static void phylink_del_pcs(struct phylink *pl, struct phylink_pcs *pcs)
> +{
> + lockdep_assert_held(&pl->state_mutex);
> +
> + rcu_assign_pointer(pcs->phylink, NULL);
> + synchronize_rcu();
> + list_del(&pcs->list);
> +
> + /*
> + * Check if we are removing the PCS currently
> + * in use by this phylink instance. If this is the case,
> + * tear down the link, force phylink resolve to reconfigure the
> + * interface mode, disable the current PCS and set the
> + * phylink PCS to NULL.
> + */
> + if (pl->pcs == pcs) {
> + if (pl->old_link_state) {
> + phylink_link_down(pl);
> + pl->old_link_state = false;
> + }
> + if (pl->cfg_link_an_mode == MLO_AN_INBAND)
> + timer_delete_sync(&pl->link_poll);
> + phylink_pcs_disable(pl->pcs);
[Severity: Medium]
Can phylink_del_pcs() call phylink_pcs_disable(pl->pcs) a second time
when the phylink instance is already stopped?
phylink_stop() sets pl->pcs_state to PCS_STATE_DOWN and calls
phylink_pcs_disable(pl->pcs) while leaving pl->pcs non-NULL. If the PCS
provider is removed while stopped, phylink_del_pcs() calls
phylink_pcs_disable(pl->pcs) again without an intervening enable,
breaking PCS drivers that refcount enable and disable calls such as
mxl862xx_pcs_disable(). Should this check pl->pcs_state !=
PCS_STATE_DOWN before disabling the PCS?
> +
> + pl->force_major_config = true;
> + WRITE_ONCE(pl->pcs, NULL);
> + }
> +}
[Severity: Medium]
Should pl->force_major_config be set when pl->phylink_disable_state is
non-zero?
In phylink_resolve(), pl->force_major_config bypasses the mac_config gate
that normally suppresses reconfiguration when pl->phylink_disable_state
is non-zero:
drivers/net/phy/phylink.c:phylink_resolve() {
...
if ((mac_config && link_state.interface != pl->link_config.interface) ||
pl->force_major_config) {
...
phylink_major_config(pl, false, &link_state);
pl->link_config.interface = link_state.interface;
pl->force_major_config = false;
}
}
If phylink_stop() runs phylink_run_resolve_and_disable() after
timer_delete_sync(&pl->link_poll) while pl->force_major_config is set,
phylink_major_config() reconfigures the stopping link and calls
phylink_pcs_poll_start(), which can re-arm pl->link_poll after it was
deleted. If the interface was already stopped when the PCS was removed,
pl->force_major_config stays set until the next phylink_start(), causing
phylink_enable_and_run_resolve() to run a duplicate phylink_major_config()
right after phylink_mac_initial_config().
> +
> +static int pcs_provider_notify(struct notifier_block *self,
> + unsigned long val, void *data)
> +{
> + struct phylink *pl = container_of(self, struct phylink, fwnode_pcs_nb);
> + struct fwnode_pcs_provider *pp = data;
> + struct phylink_pcs *pcs, *tmp;
> + bool resolve = false;
> +
> + rtnl_lock();
> + mutex_lock(&pl->state_mutex);
> +
> + /*
> + * Loop all the PCS for phylink instance and check if
> + * this notification is relevant for some of them.
> + */
> + list_for_each_entry_safe(pcs, tmp, &pl->pcs_list, list) {
> + if (!fwnode_pcs_matches_provider(pp, pl->fwnode, pcs))
> + continue;
> +
> + phylink_del_pcs(pl, pcs);
> + resolve = true;
> + }
> +
> + /* Exit early if nothing has changed */
> + if (!resolve) {
> + mutex_unlock(&pl->state_mutex);
> + rtnl_unlock();
> + return NOTIFY_DONE;
> + }
> +
> + /* Refresh supported interfaces */
> + phy_interface_copy(pl->supported_interfaces,
> + pl->config->supported_interfaces);
> + list_for_each_entry(pcs, &pl->pcs_list, list)
> + phy_interface_or(pl->supported_interfaces,
> + pl->supported_interfaces,
> + pcs->supported_interfaces);
[Severity: Medium]
When a PCS is removed and pl->supported_interfaces is reset from
pl->config->supported_interfaces, can __phylink_validate() still treat an
interface in pl->config->pcs_interfaces as supported without a PCS?
Drivers populate pl->config->supported_interfaces with all MAC-supported
interfaces and mark those requiring a dedicated PCS in
pl->config->pcs_interfaces. When no matching PCS remains in
pl->pcs_list, phylink_validate_mac_and_pcs() leaves pcs as NULL without
returning an error and validates against MAC capabilities alone:
drivers/net/phy/phylink.c:phylink_validate_mac_and_pcs() {
...
} else if (test_bit(state->interface, pl->config->pcs_interfaces)) {
struct phylink_pcs *tmp;
list_for_each_entry(tmp, &pl->pcs_list, list) {
if (!phylink_validate_pcs_interface(tmp, state->interface)) {
pcs = tmp;
break;
}
}
}
if (pcs) {
...
}
Should phylink_validate_mac_and_pcs() return -EINVAL when !pcs in the
pl->config->pcs_interfaces branch, matching phylink_major_config()?
> +
> + /* Recalculate capabilities */
> + phylink_calculate_capabilities(pl);
[Severity: Medium]
Does calling phylink_calculate_capabilities() from pcs_provider_notify()
clobber mode- and media-specific masks in pl->supported and
pl->link_config.advertising?
After phylink_create() runs phylink_calculate_capabilities(),
phylink_parse_mode() (for MLO_AN_INBAND), phylink_parse_fixedlink(),
phylink_bringup_phy(), or SFP insertion restrict pl->supported and
pl->link_config.advertising without updating pl->advertising. When
pcs_provider_notify() later calls phylink_calculate_capabilities(),
linkmode_xor(disabled_advertising, pl->advertising,
pl->link_config.advertising) treats those mode, PHY, or SFP restrictions
as user-disabled bits, and linkmode_fill(pl->supported) followed by
__phylink_validate() overwrites pl->supported and pl->advertising with
unconstrained MAC/PCS capabilities.
[ ... ]
> @@ -2281,10 +2379,18 @@ struct phylink *phylink_create(struct phylink_config *config,
> __set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
> timer_setup(&pl->link_poll, phylink_fixed_poll, 0);
>
> + /* First register notifier for hotplug PCS events */
> + if (!phy_interface_empty(config->pcs_interfaces)) {
> + pl->fwnode_pcs_nb.notifier_call = pcs_provider_notify;
> + register_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> + }
> +
> /* Fill the PCS list with available PCS from phylink config */
> ret = phylink_fill_available_pcs(pl, config);
> if (ret < 0)
> - goto free_pl;
> + goto unregister_pcs_notify;
> +
> + mutex_lock(&pl->state_mutex);
>
> /* Link available PCS to phylink */
> list_for_each_entry(pcs, &pl->pcs_list, list)
> @@ -2301,9 +2407,11 @@ struct phylink *phylink_create(struct phylink_config *config,
>
> phylink_calculate_capabilities(pl);
>
> + mutex_unlock(&pl->state_mutex);
> +
> ret = phylink_parse_mode(pl, fwnode);
> if (ret < 0)
> - goto unlink_pcs_list;
> + goto unregister_pcs_notify;
[Severity: Medium]
Can pcs_provider_notify() race with phylink_create() because
pl->fwnode_pcs_nb is registered before initialization finishes and
pl->state_mutex is dropped between steps?
phylink_create() is called without rtnl_lock() held, so only
pl->state_mutex serializes it against pcs_provider_notify():
CPU0 CPU1
phylink_create()
register_fwnode_pcs_notifier()
phylink_fill_available_pcs()
mutex_lock(&pl->state_mutex)
list_add_tail(&pcs->list, ...)
mutex_unlock(&pl->state_mutex)
...
mutex_lock(&pl->state_mutex)
phylink_calculate_capabilities()
mutex_unlock(&pl->state_mutex)
fwnode_pcs_del_provider()
pcs_provider_notify()
mutex_lock(&pl->state_mutex)
phylink_calculate_capabilities()
phylink_parse_mode()
linkmode_zero(pl->supported) <-- data race on pl->supported /
pl->link_config.advertising
pcs_provider_notify() can also run between phylink_fill_available_pcs()
unlocking pl->state_mutex and phylink_create() re-locking it before
pcs->phylink and pl->supported_interfaces are initialized.
[ ... ]
> @@ -2322,14 +2430,18 @@ struct phylink *phylink_create(struct phylink_config *config,
> release_link_gpio:
> if (pl->link_gpio)
> gpiod_put(pl->link_gpio);
> -unlink_pcs_list:
> +unregister_pcs_notify:
> + if (pl->fwnode_pcs_nb.notifier_call)
> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> list_for_each_entry(pcs, &pl->pcs_list, list)
> rcu_assign_pointer(pcs->phylink, NULL);
> -
> synchronize_rcu();
> -
> + /* PCS notifier might queue a resolve, cancel it */
> + cancel_work_sync(&pl->resolve);
> + mutex_lock(&pl->state_mutex);
> list_for_each_entry_safe(pcs, tmp, &pl->pcs_list, list)
> list_del(&pcs->list);
> + mutex_unlock(&pl->state_mutex);
> free_pl:
> fwnode_handle_put(pl->fwnode);
> kfree(pl);
> @@ -2355,6 +2467,10 @@ void phylink_destroy(struct phylink *pl)
> if (pl->link_gpio)
> gpiod_put(pl->link_gpio);
>
> + /* Unregister notifier for late PCS attach */
> + if (pl->fwnode_pcs_nb.notifier_call)
> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> +
> /* Remove phylink instance from every PCS */
> list_for_each_entry(pcs, &pl->pcs_list, list)
> rcu_assign_pointer(pcs->phylink, NULL);
> @@ -2367,10 +2483,14 @@ void phylink_destroy(struct phylink *pl)
>
> cancel_work_sync(&pl->resolve);
>
> + mutex_lock(&pl->state_mutex);
> +
> /* Remove every PCS from phylink PCS list */
> list_for_each_entry_safe(pcs, tmp, &pl->pcs_list, list)
> list_del(&pcs->list);
>
> + mutex_unlock(&pl->state_mutex);
[Severity: Medium]
Can unregistering pl->fwnode_pcs_nb before detaching pl->pcs_list in
phylink_destroy() and the phylink_create() error path cause a
use-after-free on struct phylink_pcs?
fwnode_pcs_del_provider() relies on fwnode_pcs_notify_list to detach all
phylink consumers before returning to the PCS provider driver, which then
frees its struct phylink_pcs:
CPU0 CPU1
phylink_destroy()
unregister_fwnode_pcs_notifier()
pcs_driver_remove()
fwnode_pcs_del_provider()
blocking_notifier_call_chain()
/* pl already unregistered */
kfree(pcs)
list_for_each_entry(pcs, ...)
rcu_assign_pointer(pcs->phylink, NULL) <-- use-after-free
synchronize_rcu()
...
list_del(&pcs->list) <-- use-after-free
Unregistering the notifier after removing all PCS entries from
pl->pcs_list and clearing pl->pcs would prevent fwnode_pcs_del_provider()
from returning while phylink still holds pointers to those PCS instances.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114104426.235620-1-ansuelsmth@gmail.com?part=8
next prev parent reply other threads:[~2026-11-15 10:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 10:43 [PATCH net-next v20 00/15] net: pcs: Introduce support for fwnode PCS Christian Marangi
2026-11-14 10:43 ` [PATCH net-next v20 01/15] net: phylink: keep and use MAC supported_interfaces in phylink struct Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 02/15] net: phylink: make PCS phylink instance access RCU protected Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 03/15] net: phylink: introduce internal phylink PCS handling Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 04/15] net: pcs: implement Firmware node support for PCS driver Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 05/15] net: phylink: save phylink instance fwnode on phylink_create Christian Marangi
2026-11-14 10:43 ` [PATCH net-next v20 06/15] net: phylink: make phylink_validate state locked Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 07/15] net: phylink: add capabilities helper and track modified advertising Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 08/15] net: phylink: support PCS provider release Christian Marangi
2026-11-15 10:45 ` sashiko-bot [this message]
2026-11-14 10:43 ` [PATCH net-next v20 09/15] net: phylink: support late PCS provider attach Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 10/15] net: Document PCS subsystem Christian Marangi
2026-11-14 10:43 ` [PATCH net-next v20 11/15] MAINTAINERS: add myself as PCS subsystem maintainer Christian Marangi
2026-11-14 10:43 ` [PATCH net-next v20 12/15] net: phylink: add .pcs_link_down PCS OP Christian Marangi
2026-11-14 10:43 ` [PATCH net-next v20 13/15] dt-bindings: net: pcs: Document support for Airoha Ethernet PCS Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 14/15] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 10:43 ` [PATCH net-next v20 15/15] net: airoha: add phylink support Christian Marangi
2026-11-15 10:45 ` sashiko-bot
2026-11-14 13:27 ` [PATCH net-next v20 00/15] net: pcs: Introduce support for fwnode PCS Frank Wunderlich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-215399@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ansuelsmth@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox