From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
SimonP <simonp.git@mailbox.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
Date: Mon, 12 Oct 2026 10:10:32 -0700 [thread overview]
Message-ID: <as0UiAF45D83w2ph@google.com> (raw)
In-Reply-To: <20261012165651.130826-1-pbonzini@redhat.com>
On Mon, Oct 12, 2026, Paolo Bonzini wrote:
> When running Hyper-V from Windows 11, KVM is seeing the SS bit set
> in nested page fault error codes produced for shadowed NPT. The AMD
> manual is unclear about when SS is set, including whether it can be set
> when SupervisorShadowStackEn (bit 6) is not set in the MISC_CTL field
> of the VMCB.
>
> Nevertheless, the unexpected SS bit causes out of bounds accesses in
> permission_fault(), seen as either WARNs or UBSAN reports:
>
> kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27
> kernel: index 34 is out of range for type 'u16 [16]'
>
> (in this case, the page fault error code is 34*2=0x44, i.e. SS|U; the
> report shows SS|U|W happening as well). Fix the handling of unknown
> error codes by dropping SS and (with a WARN) any bits not among those
> that permission_fault() expects to receive.
>
> At the same time, given the uncertainty about when hardware sets SS,
> follow the processor's behavior when constructing the fault's error
> code, and preserve the SS bit as passed to FNAME(walk_addr_generic).
> While the behavior is surprising, there's a possibility that Hyper-V
> expects it (Hyper-V does not even enable CET unless it finds MBEC/GMET!),
> so retain the information when reflecting the fault to L1 instead of
> unconditionally discarding it.
>
> Bisection shows that this started happening with commit 687ee95c1b6d ("KVM:
> nSVM: enable GMET for guests"), even though SHSTK was available to guests
> since Linux 6.18. However, this is not because bit 1 of MISC_CTL (GMET)
> somehow enables reporting the SS bit; rather, it's simply that Hyper-V
> never uses CET unless GMET is also present. The WARN is reproducible
> even with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase
> to ensure that the first access to the shadow stack triggers a page fault.
>
> Reported-by: SimonP <simonp.git@mailbox.org>
Can you add a Closes when applying/pushing? It really does help archeologists
piece things together.
Closes: https://lore.kernel.org/all/asUqYEisPp9MJ8mQ@rika.bernkas.tel
prev parent reply other threads:[~2026-10-12 17:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 16:56 [PATCH v2] KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes Paolo Bonzini
2026-10-12 17:10 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as0UiAF45D83w2ph@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=simonp.git@mailbox.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.