All of lore.kernel.org
 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: 25+ 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-09 21:37   ` Andrew Lunn
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-09 21:44   ` Andrew Lunn
2026-08-10 18:29     ` AW: " Markus Stockhausen
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-09 21:51   ` Andrew Lunn
2026-08-07 17:10 ` [PATCH net-next v13 06/11] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-08-09 21:58   ` Andrew Lunn
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-09 22:13   ` Andrew Lunn
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-09 22:15   ` Andrew Lunn
2026-08-07 17:10 ` [PATCH net-next v13 10/11] net: mdio: realtek-rtl9300: Add support for RTL839x Markus Stockhausen
2026-08-09 22:19   ` Andrew Lunn
2026-08-07 17:10 ` [PATCH net-next v13 11/11] net: mdio: realtek-rtl9300: reword Kconfig and module description Markus Stockhausen
2026-08-09 22:19   ` Andrew Lunn

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.