All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Steffen Eiden <seiden@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Ingo Franzki <ifranzki@linux.ibm.com>,
	Christoph Schlameuss <schlameuss@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	borntraeger@linux.ibm.com
Subject: Re: [PATCH v3] s390/uvdevice: Support longer secret lists
Date: Wed, 6 Nov 2024 09:10:04 +0100	[thread overview]
Message-ID: <20241106081004.16507-A-hca@linux.ibm.com> (raw)
In-Reply-To: <20241104153609.1361388-1-seiden@linux.ibm.com>

On Mon, Nov 04, 2024 at 04:36:09PM +0100, Steffen Eiden wrote:
> Enable the list IOCTL to provide lists longer than one page (85 entries).
> The list IOCTL now accepts any argument length in page granularity.
> It fills the argument up to this length with entries until the list
> ends. User space unaware of this enhancement will still receive one page
> of data and an uv_rc 0x0100.
> 
> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
> ---
>  v3: remove upper boundary (8 pages) for arg len

...

> +static int uvio_get_list(void *zpage, struct uvio_ioctl_cb *uv_ioctl)
> +{
> +	const size_t data_off = offsetof(struct uv_secret_list, secrets);
> +	u8 __user *user_buf = (u8 __user *)uv_ioctl->argument_addr;
> +	struct uv_secret_list *list = zpage;
> +	u16 num_secrets_stored = 0;
> +	size_t user_off = data_off;
> +	size_t copy_len;
> +
> +	do {
> +		uv_list_secrets(list, list->next_secret_idx, &uv_ioctl->uv_rc,
> +				&uv_ioctl->uv_rrc);
> +		if (uv_ioctl->uv_rc != UVC_RC_EXECUTED &&
> +		    uv_ioctl->uv_rc != UVC_RC_MORE_DATA)
> +			break;
> +
> +		copy_len = sizeof(list->secrets[0]) * list->num_secr_stored;
> +		WARN_ON(copy_len > sizeof(list->secrets));

Is this really possible? Without checking the documentation I guess
this is not possible and therefore the WARN_ON() should be removed.

If however this can be possible then this should be turned into a
WARN_ON_ONCE().

> +		if (copy_to_user(user_buf + user_off, list->secrets, copy_len))
> +			return -EFAULT;

...and in addition, if the above would be possible this _could_ copy
random kernel data to user space. Not good.

  parent reply	other threads:[~2024-11-06  8:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 15:36 [PATCH v3] s390/uvdevice: Support longer secret lists Steffen Eiden
2024-11-05 13:09 ` Janosch Frank
2024-11-05 16:07 ` Christoph Schlameuss
2024-11-06  8:10 ` Heiko Carstens [this message]
2024-11-06  8:54   ` Janosch Frank
2024-11-06  9:13     ` Heiko Carstens
2024-11-06 12:18       ` Steffen Eiden
2024-11-06 12:25 ` [PATCH v4] " Steffen Eiden

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=20241106081004.16507-A-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=ifranzki@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schlameuss@linux.ibm.com \
    --cc=seiden@linux.ibm.com \
    /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.