Re: [PATCH v2] cxl/events: Return IRQ_NONE when no event is pending

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The threaded IRQ handler `cxl_event_thread()` can enter an infinite loop if mailbox commands fail to clear event records on the device, or if a PCIe surprise removal causes the MMIO read to persistently return all 1s (~0U).
- [High] The driver blindly trusts the `record_count` and `count` fields returned by the device in mailbox payloads, leading to out-of-bounds kernel memory reads and potential information leaks.
--

commit 659b756fc25aa4e783ce4a882044a537d7b5d643
Author: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>

cxl/events: Return IRQ_NONE when no event is pending

This patch tracks whether the CXL event handler claimed the interrupt and
returns IRQ_NONE when no supported event is detected. This allows the generic
spurious-interrupt detector to identify and disable the affected IRQ during
interrupt storms where no handler claims the event.

> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index c7c91e8dc51dc..8b560cae91f2e 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
[ ... ]
> @@ -515,6 +515,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
>  	struct cxl_dev_id *dev_id = id;
>  	struct cxl_dev_state *cxlds = dev_id->cxlds;
>  	struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
> +	bool handled = false;
>  	u32 status;
>  
>  	do {
>  		/*
>  		 * CXL 3.0 8.2.8.3.1: The lower 32 bits are the status;
>  		 * ignore the reserved upper 32 bits
>  		 */
>  		status = readl(cxlds->regs.status + CXLDEV_DEV_EVENT_STATUS_OFFSET);
>  		/* Ignore logs unknown to the driver */
>  		status &= CXLDEV_EVENT_STATUS_ALL;
>  		if (!status)
>  			break;

[Severity: High]
This is a pre-existing issue, but can this loop become infinite if a PCIe
surprise removal or fatal device error occurs?

If readl() returns all 1s (~0U), status & CXLDEV_EVENT_STATUS_ALL will
still evaluate to a non-zero value, passing the if (!status) check. The
handler will then call into cxl_mem_get_event_records() where mailbox
commands will fail on the removed device, exiting without clearing the
hardware event status.

Since status is never cleared and the error handling doesn't break the
loop, this evaluates to true at the while (status) condition and repeats
indefinitely. Does this IRQF_ONESHOT threaded handler need to check for ~0U
to avoid monopolizing a CPU and preventing device teardown during hotplug
removal?

> +
> +		handled = true;
>  		cxl_mem_get_event_records(mds, status);

[Severity: High]
This isn't a bug introduced by this patch, but does this code blindly trust
the record_count returned by the device hardware?

When cxl_mem_get_event_records() calls into cxl_mem_get_records_log(), the
driver reads the count directly from the untrusted payload:

drivers/cxl/core/mbox.c:cxl_mem_get_records_log() {
    ...
    nr_rec = le16_to_cpu(payload->record_count);
    ...
    for (i = 0; i < nr_rec; i++)
        __cxl_event_trace_record(cxlmd, type, &payload->records[i]);
    ...
}

If a compromised or malicious CXL device returns an artificially large
record_count, could this read out-of-bounds kernel memory and leak it to
userspace via tracing? 

The same pattern appears in cxl_clear_event_record() and
cxl_mem_get_poison(), where the untrusted count is used as a loop bound.
Should the payload size be validated against mbox_cmd.size_out or the
maximum allocated buffer size before iterating?

>  		cond_resched();
>  	} while (status);
>  
> -	return IRQ_HANDLED;
> +	return handled ? IRQ_HANDLED : IRQ_NONE;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912093815.14455-1-shaikhkamal2012@gmail.com?part=1