Re: [PATCH v2 4/4] HID: Intel-thc-hid: Remove redundant dev_err()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Device removal manually frees non-devm DMA scatterlist buffers before disabling hardware interrupts and the threaded IRQ handler, leading to a Use-After-Free.
- [High] The primary interrupt handlers unconditionally return `IRQ_HANDLED` when the device is in the `DISABLED` state, without checking the hardware interrupt source or clearing the interrupt condition.
--

--- Patch [4]: [PATCH v2 4/4] HID: Intel-thc-hid: Remove redundant dev_err() ---
commit d99357f50f34b4097b4c3b9ec6cfab0677cc831e
Author: Pan Chuang <panchuang@vivo.com>
Subject: HID: Intel-thc-hid: Remove redundant dev_err()

This commit removes redundant driver-specific dev_err calls following
devm_request_threaded_irq failures, as detailed error messages are already
logged by the core subsystem on failure.

> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 46d3e9a019995..59f500345acbf 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -682,11 +682,8 @@ static int quicki2c_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  					quicki2c_irq_thread_handler,
>  					IRQF_ONESHOT, KBUILD_MODNAME,
>  					qcdev);

[Severity: High]
This is a pre-existing issue, but while we are touching the threaded IRQ
setup, does quicki2c_irq_quick_handler() properly handle shared INTx
interrupts?

drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c:quicki2c_irq_quick_handler() {
    ...
    if (qcdev->state == QUICKI2C_DISABLED)
        return IRQ_HANDLED;
    ...
}

The device initializes with PCI_IRQ_ALL_TYPES, allowing fallback to INTx.
If an interrupt fires when the device state is QUICKI2C_DISABLED, the
handler unconditionally returns IRQ_HANDLED without clearing the hardware
condition. Could this prevent the generic IRQ subsystem from detecting and
disabling spurious interrupts, resulting in an interrupt storm?

[Severity: Critical]
This is a pre-existing issue, but does relying on a devm-managed IRQ here
cause a use-after-free regression during driver unbind?

During driver unbind, quicki2c_remove() explicitly frees non-devm DMA
scatterlist buffers before the devm framework tears down this IRQ:

drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c:quicki2c_remove() {
    ...
    quicki2c_dma_deinit(qcdev);
    pm_runtime_get_noresume(qcdev->dev);
    quicki2c_dev_deinit(qcdev);
    ...
}

Because devres cleans up the IRQ only after remove() returns, and hardware
interrupts are disabled later in quicki2c_dev_deinit(), the IRQ can still
fire after quicki2c_dma_deinit() unmaps and frees the scatterlist arrays.

If a concurrent hardware interrupt fires, the unlocked read_dma_buffer()
might access the freed scatterlists:

drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c:read_dma_buffer() {
    ...
    sg = read_config->sgls[prd_table_index];
    ret = sg_copy_to_buffer(sg, nent, read_buff, mes_len);
    ...
}

Can this lead to memory corruption if the handler executes on freed memory?

> -	if (ret) {
> -		dev_err_once(&pdev->dev,
> -			     "Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
> +	if (ret)
>  		goto dev_deinit;
> -	}

[ ... ]

> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> index 4ae2e1718b30c..504ef3c842ab6 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> @@ -636,11 +636,8 @@ static int quickspi_probe(struct pci_dev *pdev,
>  					quickspi_irq_thread_handler,
>  					IRQF_ONESHOT, KBUILD_MODNAME,
>  					qsdev);

[Severity: High]
This isn't a bug introduced by this patch, but does the same regression
regarding shared INTx interrupts exist in quickspi_irq_quick_handler()?

drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c:quickspi_irq_quick_handler() {
    ...
    if (qsdev->state == QUICKSPI_DISABLED)
        return IRQ_HANDLED;
    ...
}

Returning IRQ_HANDLED without clearing the hardware condition might cause
an interrupt storm if the IRQ line is shared.

[Severity: Critical]
This is a pre-existing issue, but does the same use-after-free pattern
exist here during QuickSPI device removal?

drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c:quickspi_remove() {
    ...
    quickspi_dma_deinit(qsdev);
    pm_runtime_get_noresume(qsdev->dev);
    quickspi_dev_deinit(qsdev);
    ...
}

The devm-managed IRQ will remain active after quickspi_dma_deinit() frees
the scatterlists. Could a concurrent interrupt corrupt memory?

> -	if (ret) {
> -		dev_err(&pdev->dev,
> -			"Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
> +	if (ret)
>  		goto dev_deinit;
> -	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716075203.593012-1-panchuang@vivo.com?part=4