Re: [PATCH] perf/x86/intel/uncore: Re-register PMU on PCI device hot-add

[sashiko-bot@kernel.org]

Sashiko AI review found 3 potential issue(s):
- [Critical] The patch does not fully resolve the NULL pointer dereference because it ignores registration failures during hot-add, leaving the unregister function vulnerable.
- [Critical] Pre-existing Use-After-Free and state corruption when removing unregistered alias PCI devices.
- [Critical] Pre-existing Use-After-Free due to uncore box being freed while hrtimer and performance events are active.
--

commit d861b5908dfa0b5575cf18dc6c31bb0673e86c3a
Author: Guixin Liu <kanie@linux.alibaba.com>

perf/x86/intel/uncore: Re-register PMU on PCI device hot-add

This commit extends the uncore PCI bus notifier to handle
BUS_NOTIFY_ADD_DEVICE events. When a previously-registered uncore PCI device
is re-added, it calls uncore_pci_pmu_register to recreate the box and
restore the PMU state.

> diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
> index e228e564b15ea..4a8fec0590465 100644
> --- a/arch/x86/events/intel/uncore.c
> +++ b/arch/x86/events/intel/uncore.c

[ ... ]

> @@ -1284,7 +1283,16 @@ static int uncore_bus_notify(struct notifier_block *nb,
>  	if (uncore_pci_get_dev_die_info(pdev, &die))
>  		return NOTIFY_DONE;
>  
> -	uncore_pci_pmu_unregister(pmu, die);
> +	switch (action) {
> +	case BUS_NOTIFY_DEL_DEVICE:
> +		uncore_pci_pmu_unregister(pmu, die);

Are there pre-existing issues with uncore_pci_pmu_unregister during
device removal?

If a duplicate or alias PCI device mapping to the same PMU and die is
hotplugged, uncore_pci_pmu_register safely rejects it. However, if that
rejected device is later removed, could uncore_pci_pmu_unregister wrongfully
free the legitimate box belonging to the original active device, since it does
not verify device ownership?

Also, could calling uncore_pci_pmu_unregister here cause a use-after-free
if the uncore box is freed while the hrtimer and performance events are
still active?

> +		break;
> +	case BUS_NOTIFY_ADD_DEVICE:
> +		uncore_pci_pmu_register(pdev, pmu->type, pmu, die);

What happens if uncore_pci_pmu_register fails during a hot-add event, such
as when uncore_alloc_box returns -ENOMEM?

The notifier currently ignores the return value, which would leave the box
uninitialized. If the device is subsequently removed, BUS_NOTIFY_DEL_DEVICE
would unconditionally call uncore_pci_pmu_unregister.

Could this lead to a NULL pointer dereference when uncore_pci_pmu_unregister
retrieves the missing box and passes it to uncore_box_exit? Would adding a
check for a missing box in uncore_pci_pmu_unregister help prevent this?

> +		break;
> +	default:
> +		return NOTIFY_DONE;
> +	}
>  
>  	return NOTIFY_OK;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416054549.45585-1-kanie@linux.alibaba.com?part=1