On 25-08-2026 11:00, [email protected] 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 <[email protected]>
> 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/[email protected]/
> 
>> 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/[email protected]/





Reply via email to