All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shih-Yuan Lee" <fourdollars@debian.org>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v3 1/1] hwmon: (applesmc) Convert to hwmon_device_register_with_info
Date: Sat, 11 Jul 2026 05:52:05 +0000	[thread overview]
Message-ID: <20260711055206.339A01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260711053915.4834-2-fourdollars@debian.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Mixing devres-managed memory allocations with a non-devres hwmon device registration creates a lifetime mismatch leading to a Use-After-Free when the driver is unbound via sysfs.
--

--- Patch [1]: [PATCH v3 1/1] hwmon: (applesmc) Convert to hwmon_device_register_with_info ---
commit cc16bf8a12a2f101dd9a6c6d676340d91b9c4973
Author: Shih-Yuan Lee <fourdollars@debian.org>

hwmon: (applesmc) Convert to hwmon_device_register_with_info

The legacy hwmon_device_register() function is deprecated and triggers a
warning in dmesg during driver initialization. Convert the driver to use
the modern hwmon_device_register_with_info() API, moving standard
attributes to the HWMON core and dynamically allocating extra groups.

> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -1343,17 +1434,97 @@ static int __init applesmc_init(void)

[ ... ]

> +	/* Create non-standard fanX_safe attributes group */
> +	fan_safe_attrs = devm_kcalloc(&pdev->dev, smcreg.fan_count,
> +				      sizeof(*fan_safe_attrs), GFP_KERNEL);
> +	fan_safe_attr_list = devm_kcalloc(&pdev->dev, smcreg.fan_count + 1,
> +					  sizeof(*fan_safe_attr_list), GFP_KERNEL);

[ ... ]

> -	hwmon_dev = hwmon_device_register(&pdev->dev);
> +	hwmon_dev = hwmon_device_register_with_info(&pdev->dev, "applesmc", NULL,
> +						    chip, applesmc_extra_groups);

[Severity: High]
Does mixing devres-managed memory allocations with a non-devres hwmon device
registration create a lifetime mismatch?

If a privileged user unbinds the applesmc driver via sysfs, the device core
detaches the driver and releases all devres-managed allocations tied to
pdev->dev, including the fan_safe_attrs array.

However, the hwmon device remains registered because it was created with the
non-managed hwmon_device_register_with_info() in applesmc_init() and is only
unregistered during module removal.

Since the active hwmon sysfs files still reference the freed fan_safe_attrs,
could a subsequent read of a file like fan1_safe dereference a function
pointer in freed memory and lead to a use-after-free? Should this be using
devm_hwmon_device_register_with_info() instead to tie the hwmon device
lifetime to the device?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711053915.4834-2-fourdollars@debian.org?part=1

  reply	other threads:[~2026-07-11  5:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 12:32 [PATCH 0/1] hwmon: (applesmc) Convert to hwmon_device_register_with_info Shih-Yuan Lee
2026-07-10 12:32 ` [PATCH 1/1] " Shih-Yuan Lee
2026-07-10 12:47   ` sashiko-bot
2026-07-10 14:01   ` Guenter Roeck
2026-07-10 21:10     ` Armin Wolf
2026-07-10 22:28       ` Guenter Roeck
2026-07-11  2:51         ` Shih-Yuan Lee (FourDollars)
2026-07-11  3:36 ` [PATCH v2 0/1] " Shih-Yuan Lee
2026-07-11  3:37   ` [PATCH v2 1/1] " Shih-Yuan Lee
2026-07-11  3:47     ` sashiko-bot
2026-07-11  5:39 ` [PATCH v3 0/1] " Shih-Yuan Lee
2026-07-11  5:39   ` [PATCH v3 1/1] " Shih-Yuan Lee
2026-07-11  5:52     ` sashiko-bot [this message]
2026-07-11  6:06 ` [PATCH v4 0/1] " Shih-Yuan Lee
2026-07-11  6:06   ` [PATCH v4 1/1] " Shih-Yuan Lee
2026-07-11  6:17     ` sashiko-bot
2026-07-11  7:57 ` [PATCH v5 0/3] " Shih-Yuan Lee
2026-07-11  7:57   ` [PATCH v5 1/3] hwmon: (applesmc) Cache fan positions during register initialization Shih-Yuan Lee
2026-07-11  8:06     ` sashiko-bot
2026-07-11  7:57   ` [PATCH v5 2/3] hwmon: (applesmc) Fix lockless cache validation data race Shih-Yuan Lee
2026-07-11  8:10     ` sashiko-bot
2026-07-11  7:57   ` [PATCH v5 3/3] hwmon: (applesmc) Convert to hwmon_device_register_with_info Shih-Yuan Lee
2026-07-11  8:12     ` sashiko-bot
2026-07-11  9:33 ` [PATCH v6 0/3] " Shih-Yuan Lee
2026-07-11  9:33   ` [PATCH v6 1/3] hwmon: (applesmc) Cache fan positions during register initialization Shih-Yuan Lee
2026-07-11  9:42     ` sashiko-bot
2026-07-11  9:33   ` [PATCH v6 2/3] hwmon: (applesmc) Fix lockless cache validation data race Shih-Yuan Lee
2026-07-11  9:43     ` sashiko-bot
2026-07-11  9:33   ` [PATCH v6 3/3] hwmon: (applesmc) Convert to hwmon_device_register_with_info Shih-Yuan Lee
2026-07-11  9:42     ` sashiko-bot

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=20260711055206.339A01F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=fourdollars@debian.org \
    --cc=linux-hwmon@vger.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.