All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Matlack" <dmatlack@google.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
Date: Thu, 14 May 2026 00:31:10 +0000	[thread overview]
Message-ID: <20260514003111.4F10AC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260512184846.119396-3-dmatlack@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Dangling pointer in dev->liveupdate.outgoing causes Use-After-Free memory corruption and state leaks if a device is not properly unpreserved.
- [High] Missing `kho_is_enabled()` check in `pci_flb_preserve()` violates KHO subsystem guidelines.
--

commit f946f5d8b0614325899345e29b5315ff6d5139e9
Author: David Matlack <dmatlack@google.com>

PCI: liveupdate: Track outgoing preserved PCI devices

This patch adds APIs to allow drivers to notify the PCI core of which devices
are being preserved across a Live Update. It allocates a struct pci_ser via
the KHO subsystem to track the outgoing preserved devices.

> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c

[ ... ]

> @@ -74,27 +110,30 @@ static int pci_flb_preserve(struct liveupdate_flb_op_args *args)
>  
>  	size = struct_size_t(struct pci_ser, devices, max_nr_devices);
>  
> -	ser = kho_alloc_preserve(size);
> -	if (IS_ERR(ser))
> -		return PTR_ERR(ser);
> +	outgoing->ser = kho_alloc_preserve(size);

Does this allocation need to be gated by kho_is_enabled()?

If KHO is disabled, kho_alloc_preserve() will silently add tracking state
that will never be used.

> +	if (IS_ERR(outgoing->ser)) {
> +		kfree(outgoing);
> +		return PTR_ERR(outgoing->ser);
> +	}
>  
>  	pr_debug("Preserved struct pci_ser with room for %u devices\n",
>  		 max_nr_devices);

[ ... ]

>  static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
>  {
> -	struct pci_ser *ser = args->obj;
> +	struct pci_flb_outgoing *outgoing = args->obj;
>  
> -	WARN_ON_ONCE(ser->nr_devices);
> -	kho_unpreserve_free(ser);
> +	WARN_ON_ONCE(outgoing->ser->nr_devices);
> +	kho_unpreserve_free(outgoing->ser);
> +	kfree(outgoing);

If a driver fails to unpreserve a device before the FLB is torn down, this
WARN_ON_ONCE triggers, but the memory is still freed.

Does this leave dev->liveupdate.outgoing pointing to freed memory?

>  
>  	pr_debug("Unpreserved struct pci_ser\n");
>  }

[ ... ]

> +void pci_liveupdate_unpreserve(struct pci_dev *dev)
> +{
> +	struct pci_flb_outgoing *outgoing = NULL;
> +	struct pci_dev_ser *dev_ser;
> +	struct pci_ser *ser;
> +	int ret;
> +
> +	ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&outgoing);
> +
> +	if (ret || !outgoing) {
> +		pci_warn(dev, "Cannot unpreserve device without outgoing Live Update state\n");
> +		return;
> +	}
> +
> +	guard(mutex)(&outgoing->lock);
> +	ser = outgoing->ser;
> +
> +	guard(write_lock)(&dev->liveupdate.lock);
> +
> +	dev_ser = dev->liveupdate.outgoing;
> +	if (!dev_ser) {
> +		pci_warn(dev, "Cannot unpreserve device that is not preserved\n");
> +		return;
> +	}
> +
> +	pci_info(dev, "Device will no longer be preserved across next Live Update\n");
> +	ser->nr_devices--;
> +	memset(dev_ser, 0, sizeof(*dev_ser));

If dev->liveupdate.outgoing was left dangling from a previous torn-down
session, can this corrupt memory?

If a new Live Update session starts, pci_liveupdate_unpreserve() would
fetch the new outgoing FLB but operate on the old dangling
dev->liveupdate.outgoing pointer.

Does this code cause a use-after-free in the memset() here, as well as
corrupt the new session's counter when decrementing ser->nr_devices?

> +	dev->liveupdate.outgoing = NULL;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512184846.119396-1-dmatlack@google.com?part=2

  reply	other threads:[~2026-05-14  0:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12 18:48 [PATCH v5 00/11] PCI: liveupdate: PCI core support for Live Update David Matlack
2026-05-12 18:48 ` [PATCH v5 01/11] PCI: liveupdate: Set up FLB handler for the PCI core David Matlack
2026-05-12 18:48 ` [PATCH v5 02/11] PCI: liveupdate: Track outgoing preserved PCI devices David Matlack
2026-05-14  0:31   ` sashiko-bot [this message]
2026-05-14 18:16     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 03/11] PCI: liveupdate: Track incoming " David Matlack
2026-05-14  1:05   ` sashiko-bot
2026-05-14 18:27     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 04/11] PCI: liveupdate: Document driver binding responsibilities David Matlack
2026-05-12 18:48 ` [PATCH v5 05/11] PCI: liveupdate: Keep bus numbers constant during Live Update David Matlack
2026-05-14  1:36   ` sashiko-bot
2026-05-14 18:39     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 06/11] PCI: liveupdate: Auto-preserve upstream bridges across " David Matlack
2026-05-14  2:05   ` sashiko-bot
2026-05-14 18:41     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 07/11] PCI: liveupdate: Inherit ACS flags in incoming preserved devices David Matlack
2026-05-14  2:37   ` sashiko-bot
2026-05-14 18:46     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 08/11] PCI: liveupdate: Inherit ARI Forwarding Enable on preserved bridges David Matlack
2026-05-12 18:48 ` [PATCH v5 09/11] PCI: liveupdate: Freeze preservation status during shutdown David Matlack
2026-05-14  3:14   ` sashiko-bot
2026-05-14 18:48     ` David Matlack
2026-05-12 18:48 ` [PATCH v5 10/11] PCI: liveupdate: Do not disable bus mastering on preserved devices during kexec David Matlack
2026-05-12 18:48 ` [PATCH v5 11/11] Documentation: PCI: Add documentation for Live Update David Matlack

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=20260514003111.4F10AC19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmatlack@google.com \
    --cc=linux-pci@vger.kernel.org \
    --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.