[BUG] KVM: nSVM: vNMI vmcb02->vmcb01 egress runs for a non-nested-vNMI L1 (gated on global vnmi, not nested_vnmi_enabled)

[BUG] KVM: nSVM: vNMI vmcb02->vmcb01 egress runs for a non-nested-vNMI L1 (gated on global vnmi, not nested_vnmi_enabled)

[Amirmohammad Eftekhar]

Hi,

Reporting an nSVM vNMI fidelity bug (correctness, L1-scoped; not
memory-safety, not guest->host).

On nested VM-exit, nested_svm_vmexit() copies the virtual-NMI state from
vmcb02 back into vmcb01:

  if (vnmi) {                                             /* svm/nested.c ~1407 */
          if (vmcb02->control.int_ctl & V_NMI_BLOCKING_MASK)
                  vmcb01->control.int_ctl |= V_NMI_BLOCKING_MASK;
          else
                  vmcb01->control.int_ctl &= ~V_NMI_BLOCKING_MASK;

          if (vcpu->arch.nmi_pending) { ... V_NMI_PENDING_MASK ... }
  }

The guard is the global `vnmi` module capability, not
nested_vnmi_enabled(svm). The *ingress* side is gated correctly -- in
nested_vmcb02_prepare_control() the V_NMI_* bits are only pulled from vmcb12
when nested_vnmi_enabled(svm) is true (svm/nested.c ~888-896). The egress is
not symmetric: for an L1 that was NOT granted nested vNMI, KVM still overwrites
vmcb01's V_NMI_BLOCKING/V_NMI_PENDING from vmcb02 on every L2 round-trip, so
L1's own NMI-blocking/pending state (which KVM maintains in vmcb01's V_NMI for
such an L1) is clobbered by L2-derived bits.

Impact / class
--------------
L1-scoped fidelity (a VMEXIT-egress state-mismerge class). Victim is L1; not a
privilege boundary, not guest->host, AMD-only, and CONFIG_KVM_AMD is off on the
kvmCTF target, so this is upstream-hardening value rather than a bounty issue.

Suggested fix
-------------
Gate the egress copy on nested_vnmi_enabled(svm) to match the ingress, so a
non-nested-vNMI L1's V_NMI state in vmcb01 is left untouched across L2 entry/
exit. Happy to send the patch.

Read-confirmed against kvm-x86/next (tip of 2026-10-13); present in mainline
v7.3-rc6.

Thanks,
Amirmohammad