All of lore.kernel.org
 help / color / mirror / Atom feed
From: walter harms <wharms@bfs.de>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [patch] igbvf: integer overflow in igbvf_change_mtu()
Date: Thu, 22 Oct 2015 13:52:38 +0200	[thread overview]
Message-ID: <5628CE06.4070601@bfs.de> (raw)
In-Reply-To: <20151022091013.GC9202@mwanda>



Am 22.10.2015 11:10, schrieb Dan Carpenter:
> The "new_mtu" is between 0 and INT_MAX but when we add ETH_HLEN and
> ETH_FCS_LEN to it then it could overflow so "max_frame" is negative.  We
> cap the upper bound of "max_frame" but we don't check for negative
> values.  This leads to a static checker warning.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 297af80..fa338e0 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -2350,7 +2350,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
>  static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
>  {
>  	struct igbvf_adapter *adapter = netdev_priv(netdev);
> -	int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> +	unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>  
>  	if (new_mtu < 68 || new_mtu > INT_MAX - ETH_HLEN - ETH_FCS_LEN ||
>  	    max_frame > MAX_JUMBO_FRAME_SIZE)

Perhaps it is better to use MAX_JUMBO_FRAME_SIZE.

max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN = MAX_JUMBO_FRAME_SIZE // max valid

new_mtu=MAX_JUMBO_FRAME_SIZE-ETH_HLEN-ETH_FCS_LEN

so you can avoid adding a "new" variable INT_MAX into this context.

Note: perhaps it would be better for the flow the check new_mtu before
calculating max_frame.

btw: can someone add a comment about the magic 68 ? is there something like a min_frame_size ?
(it is a real question i have no idea)

re,
 wh

> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: kernel-janitors@vger.kernel.org
Subject: Re: [patch] igbvf: integer overflow in igbvf_change_mtu()
Date: Thu, 22 Oct 2015 11:52:38 +0000	[thread overview]
Message-ID: <5628CE06.4070601@bfs.de> (raw)
In-Reply-To: <20151022091013.GC9202@mwanda>



Am 22.10.2015 11:10, schrieb Dan Carpenter:
> The "new_mtu" is between 0 and INT_MAX but when we add ETH_HLEN and
> ETH_FCS_LEN to it then it could overflow so "max_frame" is negative.  We
> cap the upper bound of "max_frame" but we don't check for negative
> values.  This leads to a static checker warning.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 297af80..fa338e0 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -2350,7 +2350,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
>  static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
>  {
>  	struct igbvf_adapter *adapter = netdev_priv(netdev);
> -	int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> +	unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>  
>  	if (new_mtu < 68 || new_mtu > INT_MAX - ETH_HLEN - ETH_FCS_LEN ||
>  	    max_frame > MAX_JUMBO_FRAME_SIZE)

Perhaps it is better to use MAX_JUMBO_FRAME_SIZE.

max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN = MAX_JUMBO_FRAME_SIZE // max valid

new_mtu=MAX_JUMBO_FRAME_SIZE-ETH_HLEN-ETH_FCS_LEN

so you can avoid adding a "new" variable INT_MAX into this context.

Note: perhaps it would be better for the flow the check new_mtu before
calculating max_frame.

btw: can someone add a comment about the magic 68 ? is there something like a min_frame_size ?
(it is a real question i have no idea)

re,
 wh

> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2015-10-22 11:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22  9:10 [Intel-wired-lan] [patch] igbvf: integer overflow in igbvf_change_mtu() Dan Carpenter
2015-10-22  9:10 ` Dan Carpenter
2015-10-22 11:52 ` walter harms [this message]
2015-10-22 11:52   ` walter harms
2015-10-22 19:57   ` [Intel-wired-lan] " Dan Carpenter
2015-10-22 19:57     ` Dan Carpenter
2015-10-23  8:16 ` [Intel-wired-lan] " Dan Carpenter
2015-10-23  8:16   ` Dan Carpenter

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=5628CE06.4070601@bfs.de \
    --to=wharms@bfs.de \
    --cc=intel-wired-lan@osuosl.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.