[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/hypfs: check the return value of snprintf to avoid leaking stack accidently


  • To: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 25 Jul 2022 10:00:09 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GuA/4AlDLjM1fwxUGbpAWYbhTC5JycA54f/haeULPP0=; b=j0URB+1GW51TM+gchapXdgSDNwYE6kvkAGX66xQDxc12AoBmsOZw97R9fJV8UQ/pShPF5aS0UVBJ/1HzyFcwtR0dM23R0+2m7iR72FIBArRuE240c43v3XOgsRteJl3Dp9pvZe96umx02CQa5yWOqejHc5fkWHe67i9GvPrdRhUycz+h9FM9h8z5LXyunE0K9i7Mdbr+qFbIwI8JzJQPxR1CJZl/Yt3CEjK1pnoWyihzWbOcbWmRnej1mjEEbltYJJtM7UByHISnk9xEQgtE5f3WpSgL5KzKQk2xsoU1DH/JXzCI6xu2iRJ/Qw3sfvgxwcNqCxK2YKyTs7fNwFcVWw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GqJEo38bHLRwBOLcLbZeF52jujgGXcoHJxynZtbEYMnEW22l4mlGrl0czxaYfHpgxuuu6frlHXK426QCFTxnGjTogaDAYhNSHiwXMxI6II856n7Oln+fYMLNpKPi7+nfonY35zY7nfpBo1zWU+dd0kMkO1Czi74RuYL3+WSgyvn9duT9y+6Nh7bnmeaL4c4o2jedHLnJY0TEShUadM/VtEScvYp2GKzKyQruADl/IM8oxZ/q1NgslZegbopl4KVYRUDYmFGPPnUvh3O1d5Z32NKm2VGKpqstDDSHqdiPgrZ2SU2kymHD2ONNs/+WF6jUe4LCDyRTmnrJ6tG85dsoBg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 25 Jul 2022 08:00:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.07.2022 19:31, Xenia Ragiadakou wrote:
> The function snprintf() returns the number of characters that would have been
> written in the buffer if the buffer size had been sufficiently large,
> not counting the terminating null character.
> Hence, the value returned is not guaranteed to be smaller than the buffer 
> size.
> Check the return value of snprintf to prevent leaking stack contents to the
> guest by accident.
> 
> Signed-off-by: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
> ---
> I 've noticed that in general in xen the return value of snprintf is not
> checked. Is there a particular reason for this? I mean if there is no space to
> fit the entire string, is it preferable to write only a part of it instead of
> failing? If that's the case, then scnprintf could be used instead below.

You will find lack of checking particularly in cases where the buffer size
has been chosen to always fit the (expected) to-be-formatted value(s).
While in a number of (most?) cases this ends up being fragile when
considering general portability (like assuming that "unsigned int" can
always be expressed in 10 decimal digits), I guess making such assumptions
has been deemed "good enough" up until now. I think this also applies here,
so ...

> --- a/xen/common/hypfs.c
> +++ b/xen/common/hypfs.c
> @@ -377,6 +377,8 @@ int hypfs_read_dyndir_id_entry(const struct 
> hypfs_entry_dir *template,
>      unsigned int e_namelen, e_len;
>  
>      e_namelen = snprintf(name, sizeof(name), template->e.name, id);
> +    if ( e_namelen >= sizeof(name) )
> +        return -ENOBUFS;

... I wonder whether you don't want to additionally put ASSERT_UNREACHABLE()
here (but leave -ENOBUFS to keep release builds safe). (I also take it that
you haven't found an actual case of the buffer being too small here?)

But of course the main purpose of using snprintf() is to avoid buffer
overrun, so truncation is indeed deemed only secondary in many cases.
Which doesn't mean adding such checks would be unwelcome - it's just that
in some of the cases your options are limited - see e.g. the other similar
use of snprintf() in hypfs_gen_dyndir_id_entry(), where the function doesn't
presently have any error cases.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.