Re: [PATCH] PCI: hv: Warn when wait_for_response() waits indefinitely

[Sahil Chandna <sahilchandna@linux.microsoft.com>]

On 25-08-2026 11:00, sashiko-bot@kernel.org wrote:
> 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;
> [ ... ]
> 
This warning was flagged earlier as well [1], I will address this in a
separate patch.

Regards,
Sahil
[1]
https://lore.kernel.org/linux-hyperv/20260612175219.220581F000E9@smtp.kernel.org/