All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Priyank Rathod" <rathodpriyank@google.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/2] PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow
Date: Mon, 03 Aug 2026 22:04:48 +0000	[thread overview]
Message-ID: <20260803220448.DC28F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803-b4-fix-aer-memleaks-v3-1-e87159611933@google.com>

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

Pre-existing issues:
- [High] Pre-existing memory leak of `entry.regs` in `aer_recover_work_func()` when the target PCI device is not found.
--

--- Patch [1]: [PATCH v3 1/2] PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow ---
commit d5a765be7d938a7478de89568f1bd78dc7110e67
Author: Priyank Rathod <rathodpriyank@google.com>

PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow

This commit addresses a memory leak that occurs when ACPI APEI/GHES attempts
to enqueue a new AER error record but the kfifo buffer overflows. It ensures
that the dynamically allocated memory for aer_regs is properly freed using
ghes_estatus_pool_region_free() when kfifo_in_spinlocked() fails.

> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index c4fd9c0b2a548..967cde9dd5191 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1274,9 +1274,12 @@ void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
>  	if (kfifo_in_spinlocked(&aer_recover_ring, &entry, 1,
>  				 &aer_recover_ring_lock))
>  		schedule_work(&aer_recover_work);
> -	else
> +	else {
>  		pr_err("buffer overflow in recovery for %04x:%02x:%02x.%x\n",
>  		       domain, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +		ghes_estatus_pool_region_free((unsigned long)aer_regs,
> +					    sizeof(struct aer_capability_regs));
> +	}

[Severity: High]
This is a pre-existing issue, but while reviewing this fix, I noticed
another potential memory leak of entry.regs in aer_recover_work_func().

When aer_recover_work_func() dequeues an entry, it attempts to find the pdev:

drivers/pci/pcie/aer.c:aer_recover_work_func() {
	...
	while (kfifo_get(&aer_recover_ring, &entry)) {
		pdev = pci_get_domain_bus_and_slot(entry.domain, entry.bus,
						   entry.devfn);
		if (!pdev) {
			pr_err_ratelimited("%04x:%02x:%02x.%x: no pci_dev found\n",
					   ...);
			continue;
		}
	...
}

If pdev is not found, the continue statement bypasses the subsequent call to
ghes_estatus_pool_region_free().

Does this code permanently leak the constrained ghes_estatus_pool memory for
entry.regs when a device is not enumerated or hot-removed?

>  }
>  EXPORT_SYMBOL_GPL(aer_recover_queue);
>  #endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-b4-fix-aer-memleaks-v3-0-e87159611933@google.com?part=1

  reply	other threads:[~2026-08-03 22:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 21:51 [PATCH v3 0/2] (no cover subject) Priyank Rathod
2026-08-03 21:51 ` [PATCH v3 1/2] PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow Priyank Rathod
2026-08-03 22:04   ` sashiko-bot [this message]
2026-08-03 21:51 ` [PATCH v3 2/2] PCI/AER: Fix memory leak in aer_recover_work_func() when pci_dev is missing Priyank Rathod
2026-08-03 22:01   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260803220448.DC28F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rathodpriyank@google.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.