public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top, Matej Hrica <mhrica@redhat.com>
Subject: Re: [PATCH 3/4] util, lineread, tap: Overflow checks on long signed sums and subtractions
Date: Thu, 27 Jun 2024 11:13:14 +1000	[thread overview]
Message-ID: <Zny8qpnEENU0lh5g@zatzit> (raw)
In-Reply-To: <20240626234536.3306466-4-sbrivio@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6854 bytes --]

On Thu, Jun 27, 2024 at 01:45:35AM +0200, Stefano Brivio wrote:
> Potential sum and subtraction overflows were reported by Coverity in a
> few places where we use size_t and ssize_t types.
> 
> Strictly speaking, those are not false positives even if I don't see a
> way to trigger those: for instance, if we receive up to n bytes from a
> socket up, the return value from recv() is already constrained and
> can't overflow for the usage we make in tap_handler_passt().

Actually, I think they are false positives.  In a bunch of cases the
reasoning for that does rely on assuming the kernel will never return
a value greater than the buffer size for read(), write() or similar.
So possibly just ASSERT()ing that would suffice.

> In any case, take care of those by adding two functions that
> explicitly check for overflows in sums and subtractions of long signed
> values, and using them.
> 
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
>  lineread.c |  5 +++--
>  tap.c      | 21 +++++++++++++++------
>  util.c     |  7 +++++--
>  util.h     | 46 +++++++++++++++++++++++++++++++++++++++++++++-
>  4 files changed, 68 insertions(+), 11 deletions(-)
> 
> diff --git a/lineread.c b/lineread.c
> index 0387f4a..12f2d24 100644
> --- a/lineread.c
> +++ b/lineread.c
> @@ -17,6 +17,7 @@
>  #include <string.h>
>  #include <stdbool.h>
>  #include <unistd.h>
> +#include <errno.h>
>  
>  #include "lineread.h"
>  #include "util.h"
> @@ -102,8 +103,8 @@ ssize_t lineread_get(struct lineread *lr, char **line)
>  
>  		if (rc == 0)
>  			eof = true;
> -		else
> -			lr->count += rc;

From the construction of the read, lr->count + rc can never exceed
LINEREAD_BUFFER_SIZE - lr->next_line, so this can't overflow.

> +		else if (saddl_overflow(lr->count, rc, &lr->count))
> +			return -ERANGE;
>  	}
>  
>  	*line = lr->buf + lr->next_line;
> diff --git a/tap.c b/tap.c
> index ec994a2..7f8c26d 100644
> --- a/tap.c
> +++ b/tap.c
> @@ -1031,7 +1031,11 @@ redo:
>  		 */
>  		if (l2len > n) {
>  			rem = recv(c->fd_tap, p + n, l2len - n, 0);
> -			if ((n += rem) != l2len)

Similarly, rem <= l2len - n, and therefore n + rem <= l2len.

> +
> +			if (saddl_overflow(n, rem, &n))
> +				return;
> +
> +			if (n != l2len)
>  				return;
>  		}
>  
> @@ -1046,7 +1050,9 @@ redo:
>  
>  next:
>  		p += l2len;
> -		n -= l2len;

We already checked that l2len <= n, so this one can't overflow either.
Not sure why Coverity can't see that itself, though :/.  Possibly it
doesn't understand gotos well enough to see that the only goto next is
after that check.

> +
> +		if (ssubl_overflow(n, l2len, &n))
> +			return;
>  	}
>  
>  	tap_handler(c, now);
> @@ -1077,17 +1083,20 @@ redo:
>  	tap_flush_pools();
>  restart:
>  	while ((len = read(c->fd_tap, pkt_buf + n, TAP_BUF_BYTES - n)) > 0) {
> -
>  		if (len < (ssize_t)sizeof(struct ethhdr) ||
>  		    len > (ssize_t)ETH_MAX_MTU) {
> -			n += len;

Here n+len can't exceed TAP_BUF_BYTES, so again, no overflow.

> +			if (saddl_overflow(n, len, &n))
> +				return;
> +
>  			continue;
>  		}
>  
> -
>  		tap_add_packet(c, len, pkt_buf + n);
>  
> -		if ((n += len) == TAP_BUF_BYTES)

Same here.

> +		if (saddl_overflow(n, len, &n))
> +			return;
> +
> +		if (n == TAP_BUF_BYTES)
>  			break;
>  	}
>  
> diff --git a/util.c b/util.c
> index dd2e57f..a72d6c5 100644
> --- a/util.c
> +++ b/util.c
> @@ -567,7 +567,7 @@ int do_clone(int (*fn)(void *), char *stack_area, size_t stack_size, int flags,
>   *
>   * #syscalls write writev
>   */
> -int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip)
> +int write_remainder(int fd, const struct iovec *iov, int iovcnt, ssize_t skip)

I don't love this change, since negative skip values make no sense.

>  {
>  	int i;
>  	size_t offset;
> @@ -585,7 +585,10 @@ int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip)
>  		if (rc < 0)
>  			return -1;
>  
> -		skip += rc;

Ok, here it's not a false positive.  I believe this really could
overflow if you had an iov where the sum of the iov_len exceeded a
size_t.

> +		if (saddl_overflow(skip, rc, &skip)) {
> +			errno = -ERANGE;
> +			return -1;
> +		}

If you leave skip an unsigned, you've already checked for negative rc,
so this is essentially an unsigned add.  Checking for overflow on an
unsigned addition is simpler than the logic of saddl_overflow().

>  	}
>  
>  	return 0;
> diff --git a/util.h b/util.h
> index eebb027..497d2fd 100644
> --- a/util.h
> +++ b/util.h
> @@ -161,7 +161,7 @@ void pidfile_write(int fd, pid_t pid);
>  int __daemon(int pidfile_fd, int devnull_fd);
>  int fls(unsigned long x);
>  int write_file(const char *path, const char *buf);
> -int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip);
> +int write_remainder(int fd, const struct iovec *iov, int iovcnt, ssize_t skip);
>  
>  /**
>   * af_name() - Return name of an address family
> @@ -223,6 +223,50 @@ static inline bool mod_between(unsigned x, unsigned i, unsigned j, unsigned m)
>  	return mod_sub(x, i, m) < mod_sub(j, i, m);
>  }
>  
> +/**
> + * saddl_overflow() - Sum with overflow check for long signed values
> + * @a:		First value
> + * @b:		Second value
> + * @sum:	Pointer to result of sum, if it doesn't overflow
> + *
> + * Return: true if the sum would overflow, false otherwise
> + */
> +static inline bool saddl_overflow(long a, long b, long *sum)

These take long, but you're often calling them with ssize_t.  That's
_probably_ the same thing, but not necessarily.

> +{
> +#if __GNUC__
> +	return __builtin_saddl_overflow(a, b, sum);
> +#else
> +	if ((a > 0 && a > LONG_MAX - b) ||
> +	    (b < 0 && a < LONG_MIN - b))
> +		return true;
> +
> +	*sum = a + b;
> +	return false;
> +#endif
> +}
> +
> +/**
> + * saddl_overflow() - Subtraction with overflow check for long signed values

s/saddl_overflow/ssubl_overflow/

> + * @a:		Minuend
> + * @b:		Subtrahend
> + * @sum:	Pointer to result of subtraction, if it doesn't overflow
> + *
> + * Return: true if the subtraction would overflow, false otherwise
> + */
> +static inline bool ssubl_overflow(long a, long b, long *diff)
> +{
> +#if __GNUC__
> +	return __builtin_ssubl_overflow(a, b, diff);
> +#else
> +	if ((b > 0 && a < LONG_MIN + b) ||
> +	    (b < 0 && a > LONG_MAX + b))
> +		return true;
> +
> +	*diff = a - b;
> +	return false;
> +#endif
> +}
> +
>  /*
>   * Workarounds for https://github.com/llvm/llvm-project/issues/58992
>   *

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-06-27  1:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26 23:45 [PATCH 0/4] Small, assorted "hardening" fixes Stefano Brivio
2024-06-26 23:45 ` [PATCH 1/4] conf: Copy up to MAXDNSRCH - 1 bytes, not MAXDNSRCH Stefano Brivio
2024-06-27  0:45   ` David Gibson
2024-06-27  7:27     ` Stefano Brivio
2024-06-27 10:11       ` David Gibson
2024-06-26 23:45 ` [PATCH 2/4] tcp_splice: Check return value of setsockopt() for SO_RCVLOWAT Stefano Brivio
2024-06-27  0:46   ` David Gibson
2024-06-26 23:45 ` [PATCH 3/4] util, lineread, tap: Overflow checks on long signed sums and subtractions Stefano Brivio
2024-06-27  1:13   ` David Gibson [this message]
2024-06-27  7:55     ` Stefano Brivio
2024-06-27 20:46       ` Stefano Brivio
2024-06-28  7:15         ` David Gibson
2024-06-28  7:11       ` David Gibson
2024-06-28  7:55         ` Stefano Brivio
2024-06-28 18:30           ` Stefano Brivio
2024-07-08 13:01             ` Stefano Brivio
2024-06-26 23:45 ` [PATCH 4/4] tap: Drop frames from guest whose length is more than remaining buffer Stefano Brivio
2024-06-27  1:30   ` David Gibson
2024-06-27  8:21     ` Stefano Brivio
2024-06-28  7:19       ` David Gibson
2024-06-28  7:56         ` Stefano Brivio

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=Zny8qpnEENU0lh5g@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=mhrica@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).