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; [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
