Linux Watchdog driver development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rasmus Villemoes" <linux@rasmusvillemoes.dk>
Cc: linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2] watchdog: take all OF aliases into account when assigning id
Date: Tue, 14 Jul 2026 11:05:44 +0000	[thread overview]
Message-ID: <20260714110545.06D171F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714105356.2931450-1-linux@rasmusvillemoes.dk>

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

New issues:
- [Medium] The fallback ID allocation for legacy watchdog modules bypasses the new alias-aware logic, potentially stealing an ID reserved by a DT alias.

Pre-existing issues:
- [High] A pre-existing flaw in deferred watchdog registration ignores failures, leaving dangling pointers that trigger Use-After-Free and Double Free vulnerabilities when the device is subsequently unbound.
--

--- Patch [1]: [PATCH v2] watchdog: take all OF aliases into account when assigning id ---
commit 723b5098283b03dc095379b11c599fe692046472
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>

watchdog: take all OF aliases into account when assigning id

Ensure that ids for devices without a device tree alias are allocated
from among those where no watchdogX alias exists.

> diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
> --- a/drivers/watchdog/watchdog_core.c
> +++ b/drivers/watchdog/watchdog_core.c

[ ... ]

> @@ -265,8 +267,26 @@ static int ___watchdog_register_device(struct watchdog_device *wdd)
>  					     GFP_KERNEL);
>  	}
>  
> -	if (id < 0)
> -		id = ida_alloc_max(&watchdog_ida, MAX_DOGS - 1, GFP_KERNEL);
> +	/*
> +	 * Find an id which is not pre-assigned via a DT alias to some
> +	 * other, possibly not yet probed, watchdog device.
> +	 */
> +	if (id < 0) {
> +		np = of_find_node_by_path("/aliases");
> +
> +		for (min_id = 0; ; min_id = id + 1) {
> +			id = ida_alloc_range(&watchdog_ida, min_id, MAX_DOGS - 1,
> +					     GFP_KERNEL);
> +			if (!np || id < 0)
> +				break;
> +
> +			snprintf(alias, sizeof(alias), "watchdog%d", id);
> +			if (!of_get_property(np, alias, NULL))
> +				break;
> +			ida_free(&watchdog_ida, id);
> +		}
> +		of_node_put(np);
> +	}
>  
>  	if (id < 0)
>  		return id;
>  	wdd->id = id;
>  
>  	ret = watchdog_dev_register(wdd);
>  	if (ret) {
>  		ida_free(&watchdog_ida, id);
>  		if (!(id == 0 && ret == -EBUSY))
>  			return ret;
>  
>  		/* Retry in case a legacy watchdog module exists */
>  		id = ida_alloc_range(&watchdog_ida, 1, MAX_DOGS - 1,
>  				     GFP_KERNEL);

[Severity: Medium]
Does this fallback allocation for legacy modules need to validate against
DT aliases as well?

Because this path calls ida_alloc_range() directly, it bypasses the newly
introduced alias validation loop. If a legacy watchdog module causes a
retry, could this allocation steal an ID that is actively reserved for
another unprobed device via a DT alias?

[Severity: High]
This is a pre-existing issue, but I noticed a potential flaw in how
watchdog_deferred_registration() handles failures. 

If the registration fails, the return value is ignored:

drivers/watchdog/watchdog_core.c:watchdog_deferred_registration() {
    ...
    __watchdog_register_device(wdd);
    ...
}

During the failed registration attempt, watchdog_cdev_register() assigns
wdd->wd_data, but never clears it on the error path:

drivers/watchdog/watchdog_dev.c:watchdog_cdev_register() {
    ...
    wd_data->wdd = wdd;
    wdd->wd_data = wd_data;
    ...
}

If this fails, the device is left in a partially initialized state but
remains registered in devres. When the device is subsequently unbound or
the module removed, __watchdog_unregister_device() executes on the failed
device:

drivers/watchdog/watchdog_core.c:__watchdog_unregister_device() {
    ...
    watchdog_dev_unregister(wdd);
    ida_free(&watchdog_ida, wdd->id);
    ...
}

Could this trigger a use-after-free or NULL pointer dereference inside
watchdog_dev_unregister(), as well as a double-free on the IDA since the
ID was already freed during the initial registration failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714105356.2931450-1-linux@rasmusvillemoes.dk?part=1

      reply	other threads:[~2026-07-14 11:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 10:53 [PATCH v2] watchdog: take all OF aliases into account when assigning id Rasmus Villemoes
2026-07-14 11:05 ` sashiko-bot [this message]

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=20260714110545.06D171F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --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