)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"e12e540ecaf36653808dc25b9d0b80ae8fc09341","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"0e0d92e9_a029b3c9","updated":"2026-09-10 05:27:54.000000000","message":"recheck","commit_id":"8ff623a617f7a4b9e2af3b28815414d432a886dc"}],"pci-sim/test_pci_sim_nvme_host.sh":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"c09d896f37aef0b0e48f2009373594bef7173174","unresolved":false,"context_lines":[{"line_number":182,"context_line":"MODULE_SANICAP\u003d$(cat \\"},{"line_number":183,"context_line":"    /sys/module/fake_pci_sriov/parameters/nvme_sanicap \\"},{"line_number":184,"context_line":"    2\u003e/dev/null || echo 0)"},{"line_number":185,"context_line":"CTRL_SANICAP\u003d$(nvme id-ctrl /dev/nvme0 2\u003e/dev/null | \\"},{"line_number":186,"context_line":"    awk \u0027/^sanicap/{print $3}\u0027)"},{"line_number":187,"context_line":"echo \"    module nvme_sanicap\u003d$MODULE_SANICAP  id-ctrl sanicap\u003d$CTRL_SANICAP\""},{"line_number":188,"context_line":"if [ \"$((MODULE_SANICAP))\" -eq \"$((CTRL_SANICAP))\" ] 2\u003e/dev/null; then"}],"source_content_type":"text/x-sh","patch_set":2,"id":"37719bcd_ff674116","line":185,"updated":"2026-09-09 16:24:21.000000000","message":"The new sanitize coverage block in test_pci_sim_nvme_host.sh issues destructive \u0027nvme sanitize\u0027 commands against a hardcoded /dev/nvme0 instead of the $NVME_DEV variable that the script resolves from the VF PCI address and validates with an id-ctrl vid check specifically \u0027to avoid destructive ops on wrong device\u0027 (e.g. the real NVMe boot disk). The earlier vid guard protects $NVME_DEV only; the new sanitize block sends commands to whatever device happens to own /dev/nvme0.\n\n**Severity**: HIGH | **Confidence**: 0.75\n\n**Impact**: On a host where a real NVMe controller owns /dev/nvme0 (e.g. the boot disk), running this root-level test script issues real Sanitize NVM commands to that controller, potentially destroying data. The script\u0027s existing vid-guard design explicitly exists to prevent exactly this class of accident.\n\n**Priority**: Before merge\n**Recommendation**:\nUse \"$NVME_DEV\" in every new sanitize invocation and in the id-ctrl sanicap read, matching the pattern of the write-zeroes test at line 171. In the restriction-test reload block, re-resolve the char device from the VF PCI address after re-creating the VFs (and re-check vid) rather than assuming /dev/nvme0.","commit_id":"8ff623a617f7a4b9e2af3b28815414d432a886dc"}]}