[PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[Mario Limonciello]

Sashiko flagged a few instances that could trigger out of bounds or
use-after-free.  This series fixes them.

Mario Limonciello (3):
  platform/x86/amd: hfi: Fix a use-after-free when unloading the driver
  platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking
    data
  platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy
    device

 drivers/platform/x86/amd/hfi/hfi.c | 34 ++++++++++++++++++------------
 1 file changed, 21 insertions(+), 13 deletions(-)

-- 
2.55.0

[PATCH 1/3] platform/x86/amd: hfi: Fix a use-after-free when unloading the driver

[Mario Limonciello]

amd_hfi_probe() registers CPU hotplug callbacks with
cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ...) and schedules the static
sched_amd_hfi_itmt_work work item, but amd_hfi_remove() tears down
neither.  The dynamically assigned hotplug state returned by
cpuhp_setup_state() is discarded, so cpuhp_remove_state() can never be
called, and the pending work is never cancelled.

After the module is unloaded and its memory is freed, any subsequent CPU
hotplug event or execution of the scheduled work dereferences the stale
callback and work function pointers, resulting in a use-after-free and
kernel panic.

Store the hotplug state returned by cpuhp_setup_state() and, on removal,
call cpuhp_remove_state() to unregister the callbacks and
cancel_work_sync() to flush the scheduled work before the module memory
goes away.

Cc: stable@vger.kernel.org
Fixes: bb20421c05fc ("platform/x86: hfi: Add online and offline callback support")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/platform/x86/amd/hfi/hfi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
index e0ebcb0c4acde..e1c776b71f3e6 100644
--- a/drivers/platform/x86/amd/hfi/hfi.c
+++ b/drivers/platform/x86/amd/hfi/hfi.c
@@ -76,6 +76,8 @@ struct amd_hfi_data {
 	struct amd_shmem_info	*shmem;
 
 	struct dentry *dbgfs_dir;
+
+	int cpuhp_state;
 };
 
 /**
@@ -244,6 +246,8 @@ static void amd_hfi_remove(struct platform_device *pdev)
 {
 	struct amd_hfi_data *dev = platform_get_drvdata(pdev);
 
+	cpuhp_remove_state(dev->cpuhp_state);
+	cancel_work_sync(&sched_amd_hfi_itmt_work);
 	debugfs_remove_recursive(dev->dbgfs_dir);
 }
 
@@ -494,6 +498,7 @@ static int amd_hfi_probe(struct platform_device *pdev)
 				amd_hfi_online, amd_hfi_offline);
 	if (ret < 0)
 		return ret;
+	amd_hfi_data->cpuhp_state = ret;
 
 	schedule_work(&sched_amd_hfi_itmt_work);
 
-- 
2.55.0

Re: [PATCH 1/3] platform/x86/amd: hfi: Fix a use-after-free when unloading the driver

[Mario Limonciello]

On 9/21/26 12:04, Mario Limonciello wrote:
> amd_hfi_probe() registers CPU hotplug callbacks with
> cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ...) and schedules the static
> sched_amd_hfi_itmt_work work item, but amd_hfi_remove() tears down
> neither.  The dynamically assigned hotplug state returned by
> cpuhp_setup_state() is discarded, so cpuhp_remove_state() can never be
> called, and the pending work is never cancelled.
> 
> After the module is unloaded and its memory is freed, any subsequent CPU
> hotplug event or execution of the scheduled work dereferences the stale
> callback and work function pointers, resulting in a use-after-free and
> kernel panic.
> 
> Store the hotplug state returned by cpuhp_setup_state() and, on removal,
> call cpuhp_remove_state() to unregister the callbacks and
> cancel_work_sync() to flush the scheduled work before the module memory
> goes away.
> 
> Cc: stable@vger.kernel.org
> Fixes: bb20421c05fc ("platform/x86: hfi: Add online and offline callback support")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: 
https://sashiko.dev/#/bug/linux-e2a43433-2732-4af4-97f1-ec320a95f087> ---
>   drivers/platform/x86/amd/hfi/hfi.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
> index e0ebcb0c4acde..e1c776b71f3e6 100644
> --- a/drivers/platform/x86/amd/hfi/hfi.c
> +++ b/drivers/platform/x86/amd/hfi/hfi.c
> @@ -76,6 +76,8 @@ struct amd_hfi_data {
>   	struct amd_shmem_info	*shmem;
>   
>   	struct dentry *dbgfs_dir;
> +
> +	int cpuhp_state;
>   };
>   
>   /**
> @@ -244,6 +246,8 @@ static void amd_hfi_remove(struct platform_device *pdev)
>   {
>   	struct amd_hfi_data *dev = platform_get_drvdata(pdev);
>   
> +	cpuhp_remove_state(dev->cpuhp_state);
> +	cancel_work_sync(&sched_amd_hfi_itmt_work);
>   	debugfs_remove_recursive(dev->dbgfs_dir);
>   }
>   
> @@ -494,6 +498,7 @@ static int amd_hfi_probe(struct platform_device *pdev)
>   				amd_hfi_online, amd_hfi_offline);
>   	if (ret < 0)
>   		return ret;
> +	amd_hfi_data->cpuhp_state = ret;
>   
>   	schedule_work(&sched_amd_hfi_itmt_work);
>   

[PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data

[Mario Limonciello]

amd_hfi_fill_metadata() parses CPU core ranking data out of the
firmware-provided PCC shared memory but trusts two values it should not:

 - n_bitmaps is used to bound the outer loop that reads the APIC ID
   bitmaps from table_data[], but it is never validated against the size
   of the shared memory region (pcct_ext->length).  A firmware-supplied
   count larger than the region reads past the end of table_data.

 - When resolving the base of the ranking data for a processor, the
   pointer is shifted by an extra "i * nr_class" term, where i is the
   current bitmap index.  The per-processor offset is already applied
   through apic_index, which uses the running count of active processors
   (apic_start).  The extra shift compounds for every logical processor
   beyond the first bitmap (APIC ID >= 32), reading out of bounds.

Both result in out-of-bounds reads that can corrupt the ranking metrics,
oops, or otherwise destabilise the system.

Reject an n_bitmaps value that would not fit within the shared memory
region, and drop the bogus "i * nr_class" term so the ranking data is
addressed only through its correct per-processor offset.

Cc: stable@vger.kernel.org
Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/platform/x86/amd/hfi/hfi.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
index e1c776b71f3e6..6d1d3b6c28a97 100644
--- a/drivers/platform/x86/amd/hfi/hfi.c
+++ b/drivers/platform/x86/amd/hfi/hfi.c
@@ -20,6 +20,7 @@
 #include <linux/module.h>
 #include <linux/mailbox_client.h>
 #include <linux/mutex.h>
+#include <linux/overflow.h>
 #include <linux/percpu-defs.h>
 #include <linux/platform_device.h>
 #include <linux/smp.h>
@@ -168,6 +169,21 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
 		return -EINVAL;
 	}
 
+	/*
+	 * The bitmaps enumerating the APIC IDs occupy the first n_bitmaps
+	 * words of table_data.  Reject a firmware-provided count that would
+	 * push those reads past the end of the shared memory region.
+	 */
+	if (struct_size(amd_hfi_data->shmem, table_data, amd_hfi_data->shmem->n_bitmaps) >
+	    pcct_ext->length) {
+		dev_err(amd_hfi_data->dev, "invalid number of bitmaps: %u\n",
+			amd_hfi_data->shmem->n_bitmaps);
+		return -EINVAL;
+	}
+
+	/* The ranking data for each processor follows the bitmaps */
+	u32 *table = amd_hfi_data->shmem->table_data + amd_hfi_data->shmem->n_bitmaps;
+
 	for (unsigned int i = 0; i < amd_hfi_data->shmem->n_bitmaps; i++) {
 		u32 bitmap = amd_hfi_data->shmem->table_data[i];
 
@@ -192,10 +208,6 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
 			info = per_cpu_ptr(&amd_hfi_cpuinfo, cpu_index);
 			apic_index = apic_start * info->nr_class * 2;
 			for (unsigned int k = 0; k < info->nr_class; k++) {
-				u32 *table = amd_hfi_data->shmem->table_data +
-					     amd_hfi_data->shmem->n_bitmaps +
-					     i * info->nr_class;
-
 				info->amd_hfi_classes[k].eff = table[apic_index + 2 * k];
 				info->amd_hfi_classes[k].perf = table[apic_index + 2 * k + 1];
 			}
-- 
2.55.0

Re: [PATCH 2/3] platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data

[Mario Limonciello]

On 9/21/26 12:04, Mario Limonciello wrote:
> amd_hfi_fill_metadata() parses CPU core ranking data out of the
> firmware-provided PCC shared memory but trusts two values it should not:
> 
>   - n_bitmaps is used to bound the outer loop that reads the APIC ID
>     bitmaps from table_data[], but it is never validated against the size
>     of the shared memory region (pcct_ext->length).  A firmware-supplied
>     count larger than the region reads past the end of table_data.
> 
>   - When resolving the base of the ranking data for a processor, the
>     pointer is shifted by an extra "i * nr_class" term, where i is the
>     current bitmap index.  The per-processor offset is already applied
>     through apic_index, which uses the running count of active processors
>     (apic_start).  The extra shift compounds for every logical processor
>     beyond the first bitmap (APIC ID >= 32), reading out of bounds.
> 
> Both result in out-of-bounds reads that can corrupt the ranking metrics,
> oops, or otherwise destabilise the system.
> 
> Reject an n_bitmaps value that would not fit within the shared memory
> region, and drop the bogus "i * nr_class" term so the ranking data is
> addressed only through its correct per-processor offset.
> 
> Cc: stable@vger.kernel.org
> Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: 
https://sashiko.dev/#/bug/linux-bc92228c-d783-4b4b-af53-d40a346c4b05> ---
>   drivers/platform/x86/amd/hfi/hfi.c | 20 ++++++++++++++++----
>   1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
> index e1c776b71f3e6..6d1d3b6c28a97 100644
> --- a/drivers/platform/x86/amd/hfi/hfi.c
> +++ b/drivers/platform/x86/amd/hfi/hfi.c
> @@ -20,6 +20,7 @@
>   #include <linux/module.h>
>   #include <linux/mailbox_client.h>
>   #include <linux/mutex.h>
> +#include <linux/overflow.h>
>   #include <linux/percpu-defs.h>
>   #include <linux/platform_device.h>
>   #include <linux/smp.h>
> @@ -168,6 +169,21 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
>   		return -EINVAL;
>   	}
>   
> +	/*
> +	 * The bitmaps enumerating the APIC IDs occupy the first n_bitmaps
> +	 * words of table_data.  Reject a firmware-provided count that would
> +	 * push those reads past the end of the shared memory region.
> +	 */
> +	if (struct_size(amd_hfi_data->shmem, table_data, amd_hfi_data->shmem->n_bitmaps) >
> +	    pcct_ext->length) {
> +		dev_err(amd_hfi_data->dev, "invalid number of bitmaps: %u\n",
> +			amd_hfi_data->shmem->n_bitmaps);
> +		return -EINVAL;
> +	}
> +
> +	/* The ranking data for each processor follows the bitmaps */
> +	u32 *table = amd_hfi_data->shmem->table_data + amd_hfi_data->shmem->n_bitmaps;
> +
>   	for (unsigned int i = 0; i < amd_hfi_data->shmem->n_bitmaps; i++) {
>   		u32 bitmap = amd_hfi_data->shmem->table_data[i];
>   
> @@ -192,10 +208,6 @@ static int amd_hfi_fill_metadata(struct amd_hfi_data *amd_hfi_data)
>   			info = per_cpu_ptr(&amd_hfi_cpuinfo, cpu_index);
>   			apic_index = apic_start * info->nr_class * 2;
>   			for (unsigned int k = 0; k < info->nr_class; k++) {
> -				u32 *table = amd_hfi_data->shmem->table_data +
> -					     amd_hfi_data->shmem->n_bitmaps +
> -					     i * info->nr_class;
> -
>   				info->amd_hfi_classes[k].eff = table[apic_index + 2 * k];
>   				info->amd_hfi_classes[k].perf = table[apic_index + 2 * k + 1];
>   			}

[PATCH 3/3] platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy device

[Mario Limonciello]

amd_hfi_init() manually registers a platform device with
platform_device_register_simple() before registering the driver.  This
device has no ACPI companion, so when amd_hfi_probe() runs for it the
acpi_match_device() check fails and probe returns -ENODEV.

The driver already advertises an ACPI match table, so the ACPI subsystem
enumerates the real AMDI0104 device and binds it to the driver.  The
manually created device therefore serves no purpose: it never binds and
lingers as an unbound platform device, wasting memory and cluttering the
device tree.

Drop the manual platform_device_register_simple() and the device that
tracked it, and rely solely on ACPI enumeration.  The CPU feature gating
in amd_hfi_init() is retained so the driver is only registered on
supported hardware.

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/platform/x86/amd/hfi/hfi.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
index 6d1d3b6c28a97..a923345dd1cf6 100644
--- a/drivers/platform/x86/amd/hfi/hfi.c
+++ b/drivers/platform/x86/amd/hfi/hfi.c
@@ -39,8 +39,6 @@
 
 #define AMD_HETERO_CPUID_27	0x80000027
 
-static struct platform_device *device;
-
 /**
  * struct amd_shmem_info - Shared memory table for AMD HFI
  *
@@ -540,12 +538,6 @@ static int __init amd_hfi_init(void)
 	    !cpu_feature_enabled(X86_FEATURE_AMD_WORKLOAD_CLASS))
 		return -ENODEV;
 
-	device = platform_device_register_simple(AMD_HFI_DRIVER, -1, NULL, 0);
-	if (IS_ERR(device)) {
-		pr_err("unable to register HFI platform device\n");
-		return PTR_ERR(device);
-	}
-
 	ret = platform_driver_register(&amd_hfi_driver);
 	if (ret)
 		pr_err("failed to register HFI driver\n");
@@ -556,7 +548,6 @@ static int __init amd_hfi_init(void)
 static __exit void amd_hfi_exit(void)
 {
 	platform_driver_unregister(&amd_hfi_driver);
-	platform_device_unregister(device);
 }
 module_init(amd_hfi_init);
 module_exit(amd_hfi_exit);
-- 
2.55.0

Re: [PATCH 3/3] platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy device

[Mario Limonciello]

On 9/21/26 12:04, Mario Limonciello wrote:
> amd_hfi_init() manually registers a platform device with
> platform_device_register_simple() before registering the driver.  This
> device has no ACPI companion, so when amd_hfi_probe() runs for it the
> acpi_match_device() check fails and probe returns -ENODEV.
> 
> The driver already advertises an ACPI match table, so the ACPI subsystem
> enumerates the real AMDI0104 device and binds it to the driver.  The
> manually created device therefore serves no purpose: it never binds and
> lingers as an unbound platform device, wasting memory and cluttering the
> device tree.
> 
> Drop the manual platform_device_register_simple() and the device that
> tracked it, and rely solely on ACPI enumeration.  The CPU feature gating
> in amd_hfi_init() is retained so the driver is only registered on
> supported hardware.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: 
https://sashiko.dev/#/bug/linux-8791990d-979b-4901-81b0-a8c6fdb67c7a> ---
>   drivers/platform/x86/amd/hfi/hfi.c | 9 ---------
>   1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/platform/x86/amd/hfi/hfi.c b/drivers/platform/x86/amd/hfi/hfi.c
> index 6d1d3b6c28a97..a923345dd1cf6 100644
> --- a/drivers/platform/x86/amd/hfi/hfi.c
> +++ b/drivers/platform/x86/amd/hfi/hfi.c
> @@ -39,8 +39,6 @@
>   
>   #define AMD_HETERO_CPUID_27	0x80000027
>   
> -static struct platform_device *device;
> -
>   /**
>    * struct amd_shmem_info - Shared memory table for AMD HFI
>    *
> @@ -540,12 +538,6 @@ static int __init amd_hfi_init(void)
>   	    !cpu_feature_enabled(X86_FEATURE_AMD_WORKLOAD_CLASS))
>   		return -ENODEV;
>   
> -	device = platform_device_register_simple(AMD_HFI_DRIVER, -1, NULL, 0);
> -	if (IS_ERR(device)) {
> -		pr_err("unable to register HFI platform device\n");
> -		return PTR_ERR(device);
> -	}
> -
>   	ret = platform_driver_register(&amd_hfi_driver);
>   	if (ret)
>   		pr_err("failed to register HFI driver\n");
> @@ -556,7 +548,6 @@ static int __init amd_hfi_init(void)
>   static __exit void amd_hfi_exit(void)
>   {
>   	platform_driver_unregister(&amd_hfi_driver);
> -	platform_device_unregister(device);
>   }
>   module_init(amd_hfi_init);
>   module_exit(amd_hfi_exit);

Re: [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[Ilpo Järvinen]

On Mon, 21 Sep 2026, Mario Limonciello wrote:

> Sashiko flagged a few instances that could trigger out of bounds or
> use-after-free.  This series fixes them.

Hi,

I suppose it would be fair to credit sashiko with tags.

> Mario Limonciello (3):
>   platform/x86/amd: hfi: Fix a use-after-free when unloading the driver
>   platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking
>     data
>   platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy
>     device
> 
>  drivers/platform/x86/amd/hfi/hfi.c | 34 ++++++++++++++++++------------
>  1 file changed, 21 insertions(+), 13 deletions(-)
> 
> 

-- 
 i.

Re: [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[Mario Limonciello]

On 9/21/26 12:10, Ilpo Järvinen wrote:
> On Mon, 21 Sep 2026, Mario Limonciello wrote:
> 
>> Sashiko flagged a few instances that could trigger out of bounds or
>> use-after-free.  This series fixes them.
> 
> Hi,
> 
> I suppose it would be fair to credit sashiko with tags.
> 
>> Mario Limonciello (3):
>>    platform/x86/amd: hfi: Fix a use-after-free when unloading the driver
>>    platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking
>>      data
>>    platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy
>>      device
>>
>>   drivers/platform/x86/amd/hfi/hfi.c | 34 ++++++++++++++++++------------
>>   1 file changed, 21 insertions(+), 13 deletions(-)
>>
>>
> 

What tag would I use?  The Sashiko URLs appear to be private (or at 
least I need to be logged in).

Something like:

Reported-by: Sashiko

or

Reported-by: Sashiko
Closes: <private-sashiko-url>

Re: [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Mon, 21 Sep 2026, Mario Limonciello wrote:
> On 9/21/26 12:10, Ilpo Järvinen wrote:
> > On Mon, 21 Sep 2026, Mario Limonciello wrote:
> > 
> > > Sashiko flagged a few instances that could trigger out of bounds or
> > > use-after-free.  This series fixes them.
> > 
> > Hi,
> > 
> > I suppose it would be fair to credit sashiko with tags.
> > 
> > > Mario Limonciello (3):
> > >    platform/x86/amd: hfi: Fix a use-after-free when unloading the driver
> > >    platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking
> > >      data
> > >    platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy
> > >      device
> > > 
> > >   drivers/platform/x86/amd/hfi/hfi.c | 34 ++++++++++++++++++------------
> > >   1 file changed, 21 insertions(+), 13 deletions(-)
> > > 
> > > 
> > 
> 
> What tag would I use?  The Sashiko URLs appear to be private (or at least I
> need to be logged in).
> 
> Something like:
> 
> Reported-by: Sashiko
> 
> or
> 
> Reported-by: Sashiko
> Closes: <private-sashiko-url>

People have used:

Reported-by: Sashiko <sashiko-bot@kernel.org>
+ Closes tag

For the publically reviewed patches, the patches and their comments can be 
looked up from https://sashiko.dev . I'm not logged anywhere and can 
access at least those urls just fine. But if you for some reason cannot 
find a working link (w/o requiring login), we can just leave the Closes 
tag out.


-- 
 i.

Re: [PATCH 0/3] Fix a few Sashiko flagged issues on AMD_HFI

[Mario Limonciello]

On 9/21/26 12:22, Ilpo Järvinen wrote:
> On Mon, 21 Sep 2026, Mario Limonciello wrote:
>> On 9/21/26 12:10, Ilpo Järvinen wrote:
>>> On Mon, 21 Sep 2026, Mario Limonciello wrote:
>>>
>>>> Sashiko flagged a few instances that could trigger out of bounds or
>>>> use-after-free.  This series fixes them.
>>>
>>> Hi,
>>>
>>> I suppose it would be fair to credit sashiko with tags.
>>>
>>>> Mario Limonciello (3):
>>>>     platform/x86/amd: hfi: Fix a use-after-free when unloading the driver
>>>>     platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking
>>>>       data
>>>>     platform/x86/amd: hfi: Rely on ACPI enumeration instead of a dummy
>>>>       device
>>>>
>>>>    drivers/platform/x86/amd/hfi/hfi.c | 34 ++++++++++++++++++------------
>>>>    1 file changed, 21 insertions(+), 13 deletions(-)
>>>>
>>>>
>>>
>>
>> What tag would I use?  The Sashiko URLs appear to be private (or at least I
>> need to be logged in).
>>
>> Something like:
>>
>> Reported-by: Sashiko
>>
>> or
>>
>> Reported-by: Sashiko
>> Closes: <private-sashiko-url>
> 
> People have used:
> 
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> + Closes tag
> 
> For the publically reviewed patches, the patches and their comments can be
> looked up from https://sashiko.dev . I'm not logged anywhere and can
> access at least those urls just fine. But if you for some reason cannot
> find a working link (w/o requiring login), we can just leave the Closes
> tag out.
> 
> 

I don't actually know if the URL is secret to me or if it's just anyone 
can sign into Sashiko to access it.  I'll reply with tags to each patch 
and you can decide whether to incorporate the Closes or not.