Skip to contentSkip to conversation

igbvf: integer overflow in igbvf_change_mtu()

PATCH New Dan Carpenter 2 participants 4 messages Oct 22, 2015 – Oct 23, 2015

Subsystems (3)
Network drivers Kernel janitors Intel Ethernet
lore
Share & tools
lore

Dan Carpenter

author
#0 lore raw

PATCH 1/1 igbvf: integer overflow in igbvf_change_mtu()

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 <[email protected]>
drivers/net/ethernet/intel/igbvf/netdev.c +1 -1
index 297af80..fa338e0 100644
@@ -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)
#1 lore raw

PATCH 1/1 igbvf: integer overflow in igbvf_change_mtu()

Am 22.10.2015 11:10, schrieb Dan Carpenter:

Quoted 12 lines

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 <[email protected]>
drivers/net/ethernet/intel/igbvf/netdev.c +0 -0
index 297af80..fa338e0 100644

drivers/net/ethernet/intel/igbvf/netdev.c static struct net_device_stats *igbvf_get_stats(struct net_device *netdev) · line 2356

Quoted 8 lines
drivers/net/ethernet/intel/igbvf/netdev.c +1 -1
@@ -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

Quoted 5 lines

--
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

author
#2 lore raw

PATCH 1/1 igbvf: integer overflow in igbvf_change_mtu()

Yeah, there is an integer overflow before we check but so far as I can see it is harmless. The kernel is full of harmless integer overflows. I sort of feel like this is the simplest way to write it and the other ways feel over engineered and unweildy.

Care to propose a patch, though?

regards,
dan carpenter

author
#3 lore raw

PATCH 1/1 igbvf: integer overflow in igbvf_change_mtu()

In reply to Dan Carpenter

Oh... Hm. I was a bit confused by what Walter was saying. But there already is an integer overflow check here so it can't actually be negative... I added it a couple years ago.

Forget about this patch. Sorry.

regards,
dan carpenter