Re: [PATCH 6.6.y 5/5] KVM: x86/xen: Enforce 4-byte alignment of vcpu_info registration

[Sean Christopherson <seanjc@google.com>]

On Tue, Nov 10, 2026, Sasha Levin wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> [ Upstream commit eacdb76c5f04956035c5d7f7e1973028f30684a2 ]
> 
> Xen's map_guest_area() enforces that vcpu_info is aligned to
> sizeof(xen_ulong_t). KVM has no such check, allowing a guest to
> register vcpu_info at an arbitrary byte alignment.
> 
> Enforce unconditional 4-byte alignment regardless of the current
> shinfo mode. This is sufficient because subsequent commits ensure
> that all locked atomic operations on vcpu_info fields use at most
> 32-bit accesses. Return -ENXIO on failure, matching Xen's
> map_guest_area() behaviour for unaligned requests.
> 
> Originally observed in review of an unrelated patch:
> https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org/
> 
> Cc: stable@vger.kernel.org

Huh.  Do we actually need this backported to older kernels?  I'm not opposed to
the backports, but this seems like a rather benign issue.

Oh, /facepalm.  We didn't tag these two for stable:

  https://lore.kernel.org/all/20260831213632.81023-8-dwmw2@infradead.org
  https://lore.kernel.org/all/20260831213632.81023-9-dwmw2@infradead.org

a.k.a.

  301a5ced32e08e96212b413e896ef4c32d1ce961 KVM: x86/xen: Use 32-bit atomics if vCPU's evtchn_pending_sel isn't aligned
  1835551d4304abb1edcbf5d1ba71945279051236 KVM: x86/xen: Use 32-bit locked bts for vcpu_info evtchn_pending_sel

If those cherry-pick cleanly on top of this patch, then:

  Acked-by: Sean Christopherson <seanjc@google.com>

for *this* patch.  Otherwise, I vote to scrap this unless someone cares deeply
about guarding against an oscure userspace attack.