Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Markus Stockhausen" <markus.stockhausen@gmx.de>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v13 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes
Date: Sat, 08 Aug 2026 17:12:25 +0000	[thread overview]
Message-ID: <20260808171226.288471F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807171058.522833-5-markus.stockhausen@gmx.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete mitigation for a use-after-free vulnerability: `suppress_bind_attrs = true` does not prevent UAF during probe failures or parent device removal.
--

--- Patch [4]: [PATCH net-next v13 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes ---
commit 5daa031cbe196a78cb58053e9b33430ed4fb2104
Author: Markus Stockhausen <markus.stockhausen@gmx.de>
Subject: net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes

This commit aims to mitigate a use-after-free issue by setting
suppress_bind_attrs to true, preventing sysfs unbinds on this specific driver
instance. It notes that a corrupt devicetree might produce a load failure and
a cleanup too, and that the mdiobus may outlive the devm-allocated controller
structure.

> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index 73ac5fdcd2674..1873928b362dd 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
> @@ -830,6 +830,7 @@ static struct platform_driver otto_emdio_driver = {
>  	.driver = {
>  		.name = "mdio-rtl9300",
>  		.of_match_table = otto_emdio_ids,
> +		.suppress_bind_attrs = true,

[Severity: High]
This isn't a bug introduced by this patch, but does this mitigation fully
address the use-after-free vulnerability?

The commit message correctly notes that a corrupt devicetree can produce a
load failure. If otto_emdio_probe() successfully registers the first bus but
fails on a subsequent child node, the driver will unwind its devres
allocations:

drivers/net/mdio/mdio-realtek-rtl9300.c:otto_emdio_probe() {
    ...
	device_for_each_child_node_scoped(dev, child) {
		err = otto_emdio_probe_one(dev, priv, child);
		if (err)
			return err;
	}
    ...
}

If this happens, the central priv structure (allocated via devm_kzalloc) is
freed by devres. A concurrently probing MAC driver could have already acquired
a reference to a PHY on the successfully registered first bus, which will keep
the mii_bus alive.

When the MAC driver subsequently accesses the PHY, could it trigger a
use-after-free by attempting to access the freed priv pointer?

Setting suppress_bind_attrs to true only prevents manual sysfs unbinds on this
specific child driver instance. Will this leave the probe-failure and parent
device removal use-after-free paths exposed?

>  	},
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807171058.522833-1-markus.stockhausen@gmx.de?part=4

  reply	other threads:[~2026-08-08 17:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 17:10 [PATCH net-next v13 00/11] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 01/11] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 02/11] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 03/11] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-08-08 17:12   ` sashiko-bot
2026-08-07 17:10 ` [PATCH net-next v13 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes Markus Stockhausen
2026-08-08 17:12   ` sashiko-bot [this message]
2026-08-07 17:10 ` [PATCH net-next v13 05/11] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 06/11] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 07/11] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 08/11] net: mdio: realtek-rtl9300: Check for C45 support during setup Markus Stockhausen
2026-08-08 17:12   ` sashiko-bot
2026-08-07 17:10 ` [PATCH net-next v13 09/11] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-08-08 17:12   ` sashiko-bot
2026-08-07 17:10 ` [PATCH net-next v13 10/11] net: mdio: realtek-rtl9300: Add support for RTL839x Markus Stockhausen
2026-08-07 17:10 ` [PATCH net-next v13 11/11] net: mdio: realtek-rtl9300: reword Kconfig and module description Markus Stockhausen

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=20260808171226.288471F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=markus.stockhausen@gmx.de \
    --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