All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, borntraeger@de.ibm.com, cohuck@redhat.com
Subject: Re: [PATCH] kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()
Date: Mon, 9 Sep 2019 18:17:32 +0200	[thread overview]
Message-ID: <20190909181732.2d079536@redhat.com> (raw)
In-Reply-To: <18230047-35d7-2dfb-948e-2645fcab18e7@redhat.com>

On Mon, 9 Sep 2019 17:47:37 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 09.09.19 16:55, Igor Mammedov wrote:
> > If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling
> > kvm_s390_vm_start_migration(), kernel will oops with:
> >   
> 
> We usually have the subject in a "KVM: s390: ..." format. Like
> 
> "KVM: s390: check dirty_bitmap before using it as target for memset()"
> 
> >   Unable to handle kernel pointer dereference in virtual kernel address space
> >   Failing address: 0000000000000000 TEID: 0000000000000483
> >   Fault in home space mode while using kernel ASCE.
> >   AS:0000000002a2000b R2:00000001bff8c00b R3:00000001bff88007 S:00000001bff91000 P:000000000000003d
> >   Oops: 0004 ilc:2 [#1] SMP
> >   ...
> >   Call Trace:
> >   ([<001fffff804ec552>] kvm_s390_vm_set_attr+0x347a/0x3828 [kvm])
> >    [<001fffff804ecfc0>] kvm_arch_vm_ioctl+0x6c0/0x1998 [kvm]
> >    [<001fffff804b67e4>] kvm_vm_ioctl+0x51c/0x11a8 [kvm]
> >    [<00000000008ba572>] do_vfs_ioctl+0x1d2/0xe58
> >    [<00000000008bb284>] ksys_ioctl+0x8c/0xb8
> >    [<00000000008bb2e2>] sys_ioctl+0x32/0x40
> >    [<000000000175552c>] system_call+0x2b8/0x2d8
> >   INFO: lockdep is turned off.
> >   Last Breaking-Event-Address:
> >    [<0000000000dbaf60>] __memset+0xc/0xa0
> > 
> > due to ms->dirty_bitmap being NULL, which migh crash the host.  
> 
> s/migh/might/
> 
> > 
> > Make sure that ms->dirty_bitmap is set before using it or
> > print a warning and return -ENIVAL otherwise.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > 
> > PS:
> >   keeping it private for now as issue might DoS host,
> >   I'll leave it upto maintainers to decide if it should be handled as security
> >   bug (I'm not sure what process for handling such bugs should be used).
> > 
> > 
> >  arch/s390/kvm/kvm-s390.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index f329dcb3f44c..dfba51c9d60c 100644
> > --- a/arch/s390/kvm/kvm-s390.c
> > +++ b/arch/s390/kvm/kvm-s390.c
> > @@ -1018,6 +1018,10 @@ static int kvm_s390_vm_start_migration(struct kvm *kvm)
> >  	/* mark all the pages in active slots as dirty */
> >  	for (slotnr = 0; slotnr < slots->used_slots; slotnr++) {
> >  		ms = slots->memslots + slotnr;
> > +		if (!ms->dirty_bitmap) {
> > +			WARN(1, "ms->dirty_bitmap == NULL\n");
> > +			return -EINVAL;
> > +		}  
> 
> if (WARN_ON_ONCE(!ms->dirty_bitmap))
> 	return -EINVAL;
> 
> But I wonder if the WARN is really needed. (or simply a wrong usage of the interface)
I added WARN because of there is no any visible sign that something
went wrong in userspace, this way at least we would have a trace of
invalid API usage.

But I can drop it if you prefer.

> 
> 
> >  		/*
> >  		 * The second half of the bitmap is only used on x86,
> >  		 * and would be wasted otherwise, so we put it to good
> >   
> 
> You should add
> 
> Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots")
> Cc: stable@vger.kernel.org # v4.19+
> 
> Thanks!


  reply	other threads:[~2019-09-09 16:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09 14:55 [PATCH] kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset() Igor Mammedov
2019-09-09 15:47 ` David Hildenbrand
2019-09-09 16:17   ` Igor Mammedov [this message]
2019-09-09 16:22     ` David Hildenbrand
2019-09-09 16:21 ` Christian Borntraeger
2019-09-10 10:21   ` Claudio Imbrenda

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=20190909181732.2d079536@redhat.com \
    --to=imammedo@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@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.