All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sahil Chandna" <sahilchandna@linux.microsoft.com>
Cc: linux-pci@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH] PCI: hv: Warn when wait_for_response() waits indefinitely
Date: Tue, 25 Aug 2026 05:30:15 +0000	[thread overview]
Message-ID: <20260825053015.B26731F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825051850.2438816-1-sahilchandna@linux.microsoft.com>

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

Pre-existing issues:
- [Critical] Use-After-Free on Error Path for VMbus Completion Packets
--

--- Patch [1]: [PATCH] PCI: hv: Warn when wait_for_response() waits indefinitely ---
commit 7a3f315fe3798f61aaba375b4ed84ec32d84ef0f
Author: Sahil Chandna <sahilchandna@linux.microsoft.com>
PCI: hv: Warn when wait_for_response() waits indefinitely

This commit adds a periodic warning to wait_for_response() if the guest waits
too long for a rescind message or packet completion. This makes indefinite hangs
visible in the guest's kernel log so they can be correlated with host-side state.

Link: https://lore.kernel.org/linux-hyperv/20260612174010.2598695-1-hamzamahfooz@linux.microsoft.com/

> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index cfc8fa403dad6..c4fba00391649 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
[ ... ]
>  static int wait_for_response(struct hv_device *hdev,
>  			     struct completion *comp)
>  {
> +	unsigned long delay = secs_to_jiffies(PCI_RESPONSE_HANG_TIMEOUT_SEC);
> +	u64 timeout = get_jiffies_64() + delay;
> +
>  	while (true) {
>  		if (hdev->channel->rescind) {
>  			dev_warn_once(&hdev->device, "The device is gone.\n");
>  			return -ENODEV;

[Severity: Critical]
This is a pre-existing issue, but does this early return on rescind lead to a
use-after-free for the completion packets?

When wait_for_response() detects hdev->channel->rescind and returns -ENODEV,
callers like hv_read_config_block() will immediately return and unwind their
stack:

drivers/pci/controller/pci-hyperv.c:hv_read_config_block() {
    ...
    ret = wait_for_response(hbus->hdev, &comp_pkt.comp_pkt.host_event);
    if (ret)
        return ret;
    ...
}

This pops the stack frame containing the completion context without
deregistering the request. If a late completion packet arrives, wouldn't
hv_pci_onchannelcallback() retrieve the dangling pointer and execute the
invalid completion function?

drivers/pci/controller/pci-hyperv.c:hv_pci_onchannelcallback() {
    ...
            comp_packet = (struct pci_packet *)req_addr;
            response = (struct pci_response *)buffer;
            ...
            comp_packet->completion_func(comp_packet->compl_ctxt,
                                         response,
                                         bytes_recvd);
    ...
}

Could this result in memory corruption or a control-flow hijack if the
hypervisor sends a completion packet after the rescind offer, but before
the channel is completely closed?

>  		}
>  
>  		if (wait_for_completion_timeout(comp, HZ / 10))
>  			break;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825051850.2438816-1-sahilchandna@linux.microsoft.com?part=1

  reply	other threads:[~2026-08-25  5:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25  5:17 [PATCH] PCI: hv: Warn when wait_for_response() waits indefinitely Sahil Chandna
2026-08-25  5:30 ` sashiko-bot [this message]
2026-08-25 12:03   ` Sahil Chandna
2026-08-25  6:46 ` Naman Jain
2026-08-25 12:00   ` Sahil Chandna
2026-08-25 17:00   ` Long Li
2026-08-27 16:07     ` Michael Kelley
2026-08-27 17:34       ` Saurabh Singh Sengar
2026-08-28  5:40         ` Naman Jain
2026-08-28 14:59           ` Hamza Mahfooz
2026-09-01 11:14             ` Sahil Chandna

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=20260825053015.B26731F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sahilchandna@linux.microsoft.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.