{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()  Two bugs exist in the vCPU initialisation path:  1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup    path jumps to 'unlock' without calling unpin_host_vcpu() or    unpin_host_sve_state(), permanently leaking pin references on the    host vCPU and SVE state pages.     Extract a register_hyp_vcpu() helper that performs the checks and    the store. When register_hyp_vcpu() returns an error, call    unpin_host_vcpu() and unpin_host_sve_state() inline before falling    through to the existing 'unlock' label.  2. register_hyp_vcpu() publishes the new vCPU pointer into    'hyp_vm-\u003evcpus[]' with a bare store, allowing a concurrent caller    of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU    object.     Ensure the store uses smp_store_release() and the load uses    smp_load_acquire(). While 'vm_table_lock' currently serialises the    store and the load, these barriers ensure the reader sees the fully    initialised 'hyp_vcpu' object even if there were a lockless path or    if the lock's own ordering guarantees were insufficient for nested    object initialization.",
  "id": "DEBIAN-CVE-2026-46147",
  "modified": "2026-09-14T16:47:27.453272333Z",
  "published": "2026-05-28T10:16:30.320Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46147"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46147"
  ]
}