Re: [PATCH 1/4] kvm: sev: Fix user-space triggerable WARN_ON on snp_launch_update path

[Sean Christopherson <seanjc@google.com>]

On Fri, Jun 26, 2026, Tom Lendacky wrote:
> On 6/23/26 04:15, Jörg Rödel wrote:
> > From: Joerg Roedel <joerg.roedel@amd.com>
> > 
> > Sashiko reported on an unrelated patch:
> > 
> >   [Severity: High]
> >   This is a pre-existing issue, but can a host userspace process trigger a
> >   kernel warning by passing a NULL user address (uaddr = 0) here?
> > 
> >   If params.uaddr is 0, src becomes NULL and passes the PAGE_ALIGNED(src)
> >   check. kvm_gmem_populate() skips fetching the user page and passes
> >   src_page = NULL to sev_gmem_post_populate().
> > 
> >   That function then unconditionally evaluates:
> > 
> >   WARN_ON_ONCE(sev_populate_args->type != KVM_SEV_SNP_PAGE_TYPE_ZERO &&
> >                !src_page)
> > 
> >   Since the type isn't ZERO, won't this allow an unprivileged user to spam
> >   the kernel log?
> 
> It would only be one warning that is emitted, "spam the kernel log" sounds
> like you could fill it with warnings. And I would say that the severity is
> only "High" should the kernel be configured with PANIC_ON_WARN.

Yeah, ignore any and all complaints about panic_on_warn=1 leading to DoS.

https://lore.kernel.org/all/CABgObfZJV5hU_7WoPWLRH3-EvKts%2BUBZOwtCXmwVZYJP8dDo2A@mail.gmail.com

> > The assessment is correct, so check for this condition earlier in the
> > snp_launch_update() path to avoid the WARN_ON_ONCE.
> 
> I'm not positive, but isn't it technically possible that the userspace
> virtual address can be 0?

Yep, though it requires an explicit opt-in.

  config DEFAULT_MMAP_MIN_ADDR
	int "Low address space to protect from user allocation"
	depends on MMU
	default 4096
	help
	  This is the portion of low virtual memory which should be protected
	  from userspace allocation.  Keeping a user from writing to low pages
	  can help reduce the impact of kernel NULL pointer bugs.

	  For most ppc64 and x86 users with lots of address space
	  a value of 65536 is reasonable and should cause no problems.
	  On arm and other archs it should not be higher than 32768.
	  Programs which use vm86 functionality or have some need to map
	  this low address space will need CAP_SYS_RAWIO or disable this
	  protection by setting the value to 0.

	  This value can be changed after boot using the
	  /proc/sys/vm/mmap_min_addr tunable.

> In which case, should this be fixed in the kvm_gmem_populate() API with maybe
> a new parameter that indicates whether src is valid or not?

Nah, treating 0/NULL as invalid is perfectly acceptable.  It doesn't work today,
i.e. there's no risk of breaking anyone, and just because userspace can use VA=0
for other things doesn't mean KVM needs to support that for all of its uAPI
surface.

FWIW, I was initially opposed to using 0/NULL to mean "invalid", and even called
it ridiculous, but David W. convinced me that accepting 0/NULL in modern KVM uAPI
would violate the principle of least surprise.  So now I get to claim using NULL
to mean invalid as my own original idea ;-)

https://lore.kernel.org/all/a2cfad68277cae67791f07646c842672593a8dca.camel@infradead.org