All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Farman <farman@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	David Hildenbrand <david@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Janosch Frank <frankja@linux.vnet.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>
Subject: Re: [PATCH] s390x/sclp: pv: only copy the original SCCB buffer
Date: Wed, 19 Aug 2026 07:06:00 -0400	[thread overview]
Message-ID: <9dd7335a-1257-4aaf-9a1e-f423a04a9fe3@linux.ibm.com> (raw)
In-Reply-To: <20260814125857.1729543-1-borntraeger@de.ibm.com>



On 8/14/26 8:58 AM, Christian Borntraeger wrote:
> From: Christian Borntraeger <borntraeger@linux.ibm.com>
> 
> With variable length and EXTENDED_LENGTH_SCCB, some callbacks might
> change the length field. For example read SCP info might write a new
> length into the SCCB header. We must not use that new length for the
> buffer copy, since the buffer was allocated with the original length.
> Only the length field in the work SCCB is changed, to indicate the
> "necessary" size. Using the new length reads past the allocation, so
> tools like ASAN might detect a buffer overrun.
> 
> Secure guests do not have EXTENDED_LENGTH_SCCB, and the ultravisor checks
> and sanitizes the length field, so no qemu heap contents are exposed to
> the guest and the non pv-path already has the same header.length.
> 
> Fixes: 0f73c5b30b8b ("s390x: protvirt: SCLP interpretation")
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> ---
>   hw/s390x/sclp.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Thanks! Applied for 11.2


  parent reply	other threads:[~2026-08-19 11:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 12:58 [PATCH] s390x/sclp: pv: only copy the original SCCB buffer Christian Borntraeger
2026-08-14 17:18 ` Eric Farman
2026-08-18 21:07 ` Matthew Rosato
2026-08-19 11:06 ` Eric Farman [this message]
2026-08-20  6:35   ` Philippe Mathieu-Daudé
2026-08-27  5:52 ` Michael Tokarev

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=9dd7335a-1257-4aaf-9a1e-f423a04a9fe3@linux.ibm.com \
    --to=farman@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.vnet.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.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.