All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Cc: jgross@suse.com, sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com, bhelgaas@google.com,
	jbeulich@suse.com, konrad.wilk@oracle.com,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] xen/pcifront: check that an AER callback exists before calling it
Date: Tue, 6 Oct 2026 10:54:46 -0500	[thread overview]
Message-ID: <20261006155446.GA684274@bhelgaas> (raw)
In-Reply-To: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr>

On Tue, Oct 06, 2026 at 11:34:43AM +0900, Yehyeong Lee wrote:
> pcifront_common_process() handles an AER request from the backend by
> dispatching on aer_op.cmd to the bound driver's PCI error handler.  It
> only checks that err_handler and err_handler->error_detected are present,
> then for the mmio_enabled, slot_reset and resume commands it calls the
> corresponding callback unconditionally.  Those three callbacks are
> optional -- the PCI core NULL-checks each of them individually before
> use -- and many drivers (for example igb, igc, ice and ixgbevf) install
> error_detected without all of them.
> 
> aer_op.cmd comes from the shared ring, so a malicious or buggy backend
> can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose
> driver leaves that callback NULL and make the frontend call through a
> NULL pointer, crashing the guest.
> 
> Check each callback before calling it.  When mmio_enabled or slot_reset is
> absent, return PCI_ERS_RESULT_RECOVERED so recovery proceeds, as the PCI
> core does for a missing callback; returning PCI_ERS_RESULT_NONE would
> instead make xen-pciback tear the guest domain down.
> 
> Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
> v2: return PCI_ERS_RESULT_RECOVERED for an absent mmio_enabled/slot_reset
>     instead of PCI_ERS_RESULT_NONE, which xen-pciback treats as fatal and
>     uses to tear the domain down.  (Bjorn acked v1; the ack is dropped here
>     because v2 changes the value returned for an absent callback.)
> v1: https://lore.kernel.org/all/20261005133019.284053-1-yhlee@isslab.korea.ac.kr/
> 
> There is an in-flight fix for a refcount leak in this same function
> ("xen/pcifront: Fix PCI device reference leak in AER handling"); this
> change is orthogonal and applies in either order.
> 
>  drivers/pci/xen-pcifront.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index cffc32d660327..5c6f7796d204a 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -599,11 +599,16 @@ static pci_ers_result_t pcifront_common_process(int cmd,
>  		case XEN_PCI_OP_aer_detected:
>  			return pdrv->err_handler->error_detected(pcidev, state);
>  		case XEN_PCI_OP_aer_mmio:
> -			return pdrv->err_handler->mmio_enabled(pcidev);
> +			if (pdrv->err_handler->mmio_enabled)
> +				return pdrv->err_handler->mmio_enabled(pcidev);
> +			return PCI_ERS_RESULT_RECOVERED;
>  		case XEN_PCI_OP_aer_slotreset:
> -			return pdrv->err_handler->slot_reset(pcidev);
> +			if (pdrv->err_handler->slot_reset)
> +				return pdrv->err_handler->slot_reset(pcidev);
> +			return PCI_ERS_RESULT_RECOVERED;
>  		case XEN_PCI_OP_aer_resume:
> -			pdrv->err_handler->resume(pcidev);
> +			if (pdrv->err_handler->resume)
> +				pdrv->err_handler->resume(pcidev);
>  			return PCI_ERS_RESULT_NONE;
>  		default:
>  			dev_err(&pdev->xdev->dev,
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2026-10-06 15:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  2:34 [PATCH v2] xen/pcifront: check that an AER callback exists before calling it Yehyeong Lee
2026-10-06  2:43 ` sashiko-bot
2026-10-06 15:54 ` Bjorn Helgaas [this message]
2026-10-08 10:33 ` Juergen Gross

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=20261006155446.GA684274@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yhlee@isslab.korea.ac.kr \
    /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.