Re: [PATCH v6 4/7] mfd: mt6397: Add support for MT6392 PMIC

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The PM notifier `chip->pm_nb` and the unmanaged `irq_domain` are leaked on probe failure and driver unbind, leading to a Use-After-Free during system suspend/resume.
--

commit 7e58614b47c19c51b0d112cc3708ab6bf5ecdc5a
Author: Fabien Parent <parent.f@gmail.com>

mfd: mt6397: Add support for MT6392 PMIC

Align the MT6397 PMIC driver to other MFD drivers by passing only an
identifier through mt6397_of_match[*].data and add support for the MT6392
PMIC and its RTC, keys and pinctrl devices.

> diff --git a/drivers/mfd/mt6397-irq.c b/drivers/mfd/mt6397-irq.c
> index 5d2e5459f7444..80ea5b92d232f 100644
> --- a/drivers/mfd/mt6397-irq.c
> +++ b/drivers/mfd/mt6397-irq.c
> @@ -203,6 +205,12 @@ int mt6397_irq_init(struct mt6397_chip *chip)
>  		chip->int_status[0] = MT6397_INT_STATUS0;
>  		chip->int_status[1] = MT6397_INT_STATUS1;
>  		break;
> +	case MT6392_CHIP_ID:
> +		chip->int_con[0] = MT6392_INT_CON0;
> +		chip->int_con[1] = MT6392_INT_CON1;
> +		chip->int_status[0] = MT6392_INT_STATUS0;
> +		chip->int_status[1] = MT6392_INT_STATUS1;
> +		break;
>  
>  	default:
>  		dev_err(chip->dev, "unsupported chip: 0x%x\n", chip->chip_id);

[Severity: High]
This is a pre-existing issue, but I noticed a potential memory safety
problem involving the initialization in mt6397_irq_init() and the probe
error path in mt6397_probe().

Later in mt6397_irq_init(), we call:

    register_pm_notifier(&chip->pm_nb);

However, there doesn't seem to be a corresponding unregister_pm_notifier()
anywhere in the driver, nor a .remove callback in mt6397_driver.

If devm_mfd_add_devices() fails in mt6397_probe(), the devres mechanism
will free the mt6397_chip structure (pmic). Since the pm_nb remains
linked in the global pm_chain_head list, wouldn't a subsequent
suspend/resume event dereference the freed memory and cause a
use-after-free panic?

Additionally, could this also leak the irq_domain (created with
irq_domain_create_linear) if the driver is unbound via sysfs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612200717.361018-1-l.scorcia@gmail.com?part=4