* [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 8:03 ` Dan Carpenter
0 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 8:03 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors
If "newmtu * 2 + 4" is too large then it can cause an integer overflow
leading to memory corruption. Btw, "newmtu" is not allowed to be a
negative number because of the check in dev_set_mtu(), so that's ok.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 5895f19..f04c8c1 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -122,8 +122,11 @@ static int x25_asy_change_mtu(struct net_device *dev, int newmtu)
{
struct x25_asy *sl = netdev_priv(dev);
unsigned char *xbuff, *rbuff;
- int len = 2 * newmtu;
+ int len;
+ if (newmtu > INT_MAX / 2 - 4)
+ return -EINVAL;
+ len = 2 * newmtu;
xbuff = kmalloc(len + 4, GFP_ATOMIC);
rbuff = kmalloc(len + 4, GFP_ATOMIC);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 8:03 ` Dan Carpenter
0 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 8:03 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors
If "newmtu * 2 + 4" is too large then it can cause an integer overflow
leading to memory corruption. Btw, "newmtu" is not allowed to be a
negative number because of the check in dev_set_mtu(), so that's ok.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 5895f19..f04c8c1 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -122,8 +122,11 @@ static int x25_asy_change_mtu(struct net_device *dev, int newmtu)
{
struct x25_asy *sl = netdev_priv(dev);
unsigned char *xbuff, *rbuff;
- int len = 2 * newmtu;
+ int len;
+ if (newmtu > INT_MAX / 2 - 4)
+ return -EINVAL;
+ len = 2 * newmtu;
xbuff = kmalloc(len + 4, GFP_ATOMIC);
rbuff = kmalloc(len + 4, GFP_ATOMIC);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* RE: [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
2014-07-17 8:03 ` Dan Carpenter
(?)
@ 2014-07-17 8:45 ` David Laight
2014-07-17 8:58 ` Dan Carpenter
-1 siblings, 1 reply; 11+ messages in thread
From: David Laight @ 2014-07-17 8:45 UTC (permalink / raw)
To: 'Dan Carpenter', netdev; +Cc: kernel-janitors
From: Dan Carpenter
> If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> leading to memory corruption. Btw, "newmtu" is not allowed to be a
> negative number because of the check in dev_set_mtu(), so that's ok.
This still allows large numbers to be used to allocate almost all of
kernel memory - causing massive issues elsewhere.
I'd have thought a 'sanity' limit on the mtu would be more appropriate.
I've no idea which mtu is being changed here, and I can't even remember
the x.25 protocol well enough if it is an x.25 level 3 limit.
But I suspect that a 'sanity' bound to 1MB won't cause any grief.
David
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
> index 5895f19..f04c8c1 100644
> --- a/drivers/net/wan/x25_asy.c
> +++ b/drivers/net/wan/x25_asy.c
> @@ -122,8 +122,11 @@ static int x25_asy_change_mtu(struct net_device *dev, int newmtu)
> {
> struct x25_asy *sl = netdev_priv(dev);
> unsigned char *xbuff, *rbuff;
> - int len = 2 * newmtu;
> + int len;
>
> + if (newmtu > INT_MAX / 2 - 4)
> + return -EINVAL;
> + len = 2 * newmtu;
> xbuff = kmalloc(len + 4, GFP_ATOMIC);
> rbuff = kmalloc(len + 4, GFP_ATOMIC);
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
2014-07-17 8:45 ` David Laight
@ 2014-07-17 8:58 ` Dan Carpenter
0 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 8:58 UTC (permalink / raw)
To: David Laight; +Cc: netdev, kernel-janitors
On Thu, Jul 17, 2014 at 08:45:58AM +0000, David Laight wrote:
> From: Dan Carpenter
> > If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> > leading to memory corruption. Btw, "newmtu" is not allowed to be a
> > negative number because of the check in dev_set_mtu(), so that's ok.
>
> This still allows large numbers to be used to allocate almost all of
> kernel memory - causing massive issues elsewhere.
>
> I'd have thought a 'sanity' limit on the mtu would be more appropriate.
> I've no idea which mtu is being changed here, and I can't even remember
> the x.25 protocol well enough if it is an x.25 level 3 limit.
> But I suspect that a 'sanity' bound to 1MB won't cause any grief.
>
I agree that a sanity check is probably better but I don't think kmalloc
can allocate more than 128k (or something. It's arch dependent as
well). So using 1MB is almost no different from my original patch.
What's a better, smaller limit?
regards,
dan carpenter
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 8:58 ` Dan Carpenter
0 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 8:58 UTC (permalink / raw)
To: David Laight; +Cc: netdev, kernel-janitors
On Thu, Jul 17, 2014 at 08:45:58AM +0000, David Laight wrote:
> From: Dan Carpenter
> > If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> > leading to memory corruption. Btw, "newmtu" is not allowed to be a
> > negative number because of the check in dev_set_mtu(), so that's ok.
>
> This still allows large numbers to be used to allocate almost all of
> kernel memory - causing massive issues elsewhere.
>
> I'd have thought a 'sanity' limit on the mtu would be more appropriate.
> I've no idea which mtu is being changed here, and I can't even remember
> the x.25 protocol well enough if it is an x.25 level 3 limit.
> But I suspect that a 'sanity' bound to 1MB won't cause any grief.
>
I agree that a sanity check is probably better but I don't think kmalloc
can allocate more than 128k (or something. It's arch dependent as
well). So using 1MB is almost no different from my original patch.
What's a better, smaller limit?
regards,
dan carpenter
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
2014-07-17 8:58 ` Dan Carpenter
@ 2014-07-17 9:14 ` Eric Dumazet
-1 siblings, 0 replies; 11+ messages in thread
From: Eric Dumazet @ 2014-07-17 9:14 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David Laight, netdev, kernel-janitors
On Thu, 2014-07-17 at 11:58 +0300, Dan Carpenter wrote:
> On Thu, Jul 17, 2014 at 08:45:58AM +0000, David Laight wrote:
> > From: Dan Carpenter
> > > If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> > > leading to memory corruption. Btw, "newmtu" is not allowed to be a
> > > negative number because of the check in dev_set_mtu(), so that's ok.
> >
> > This still allows large numbers to be used to allocate almost all of
> > kernel memory - causing massive issues elsewhere.
> >
> > I'd have thought a 'sanity' limit on the mtu would be more appropriate.
> > I've no idea which mtu is being changed here, and I can't even remember
> > the x.25 protocol well enough if it is an x.25 level 3 limit.
> > But I suspect that a 'sanity' bound to 1MB won't cause any grief.
> >
>
> I agree that a sanity check is probably better but I don't think kmalloc
> can allocate more than 128k (or something. It's arch dependent as
> well). So using 1MB is almost no different from my original patch.
kmalloc() can typically allocate up to 4MB (MAX_ORDER = 11) if you are
lucky (enough contiguous memory)
Really, I do not think we should allow more than 65534 MTU, which would
allocate two 128K blocks at most.
If some bigger MTU was really needed, we would have switch to vmalloc()
a long time ago.
X.25 was limited to 4096 bytes packets if I remember well, and I used
128 and 256 only, that was a long time ago.
( link speeds were limited to 128kbps, it would be quite impractical to
use large packets...)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 9:14 ` Eric Dumazet
0 siblings, 0 replies; 11+ messages in thread
From: Eric Dumazet @ 2014-07-17 9:14 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David Laight, netdev, kernel-janitors
On Thu, 2014-07-17 at 11:58 +0300, Dan Carpenter wrote:
> On Thu, Jul 17, 2014 at 08:45:58AM +0000, David Laight wrote:
> > From: Dan Carpenter
> > > If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> > > leading to memory corruption. Btw, "newmtu" is not allowed to be a
> > > negative number because of the check in dev_set_mtu(), so that's ok.
> >
> > This still allows large numbers to be used to allocate almost all of
> > kernel memory - causing massive issues elsewhere.
> >
> > I'd have thought a 'sanity' limit on the mtu would be more appropriate.
> > I've no idea which mtu is being changed here, and I can't even remember
> > the x.25 protocol well enough if it is an x.25 level 3 limit.
> > But I suspect that a 'sanity' bound to 1MB won't cause any grief.
> >
>
> I agree that a sanity check is probably better but I don't think kmalloc
> can allocate more than 128k (or something. It's arch dependent as
> well). So using 1MB is almost no different from my original patch.
kmalloc() can typically allocate up to 4MB (MAX_ORDER = 11) if you are
lucky (enough contiguous memory)
Really, I do not think we should allow more than 65534 MTU, which would
allocate two 128K blocks at most.
If some bigger MTU was really needed, we would have switch to vmalloc()
a long time ago.
X.25 was limited to 4096 bytes packets if I remember well, and I used
128 and 256 only, that was a long time ago.
( link speeds were limited to 128kbps, it would be quite impractical to
use large packets...)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [patch v2] wan/x25_asy: integer overflow in x25_asy_change_mtu()
2014-07-17 9:14 ` Eric Dumazet
@ 2014-07-17 10:50 ` Dan Carpenter
-1 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 10:50 UTC (permalink / raw)
To: David S. Miller
Cc: Tom Gundersen, David Herrmann, netdev, Eric Dumazet,
David Laight, kernel-janitors
If "newmtu * 2 + 4" is too large then it can cause an integer overflow
leading to memory corruption. Eric Dumazet suggests that 65534 is a
reasonable upper limit.
Btw, "newmtu" is not allowed to be a negative number because of the
check in dev_set_mtu(), so that's ok.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: Cap it at 65534 instead of just testing for integer overflows.
Thanks David and Eric!
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index df6c073..5c47b01 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -122,8 +122,12 @@ static int x25_asy_change_mtu(struct net_device *dev, int newmtu)
{
struct x25_asy *sl = netdev_priv(dev);
unsigned char *xbuff, *rbuff;
- int len = 2 * newmtu;
+ int len;
+ if (newmtu > 65534)
+ return -EINVAL;
+
+ len = 2 * newmtu;
xbuff = kmalloc(len + 4, GFP_ATOMIC);
rbuff = kmalloc(len + 4, GFP_ATOMIC);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [patch v2] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 10:50 ` Dan Carpenter
0 siblings, 0 replies; 11+ messages in thread
From: Dan Carpenter @ 2014-07-17 10:50 UTC (permalink / raw)
To: David S. Miller
Cc: Tom Gundersen, David Herrmann, netdev, Eric Dumazet,
David Laight, kernel-janitors
If "newmtu * 2 + 4" is too large then it can cause an integer overflow
leading to memory corruption. Eric Dumazet suggests that 65534 is a
reasonable upper limit.
Btw, "newmtu" is not allowed to be a negative number because of the
check in dev_set_mtu(), so that's ok.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: Cap it at 65534 instead of just testing for integer overflows.
Thanks David and Eric!
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index df6c073..5c47b01 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -122,8 +122,12 @@ static int x25_asy_change_mtu(struct net_device *dev, int newmtu)
{
struct x25_asy *sl = netdev_priv(dev);
unsigned char *xbuff, *rbuff;
- int len = 2 * newmtu;
+ int len;
+ if (newmtu > 65534)
+ return -EINVAL;
+
+ len = 2 * newmtu;
xbuff = kmalloc(len + 4, GFP_ATOMIC);
rbuff = kmalloc(len + 4, GFP_ATOMIC);
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [patch v2] wan/x25_asy: integer overflow in x25_asy_change_mtu()
2014-07-17 10:50 ` Dan Carpenter
@ 2014-07-17 23:48 ` David Miller
-1 siblings, 0 replies; 11+ messages in thread
From: David Miller @ 2014-07-17 23:48 UTC (permalink / raw)
To: dan.carpenter
Cc: teg, dh.herrmann, netdev, eric.dumazet, David.Laight, kernel-janitors
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 17 Jul 2014 13:50:45 +0300
> If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> leading to memory corruption. Eric Dumazet suggests that 65534 is a
> reasonable upper limit.
>
> Btw, "newmtu" is not allowed to be a negative number because of the
> check in dev_set_mtu(), so that's ok.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Cap it at 65534 instead of just testing for integer overflows.
> Thanks David and Eric!
Applied.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch v2] wan/x25_asy: integer overflow in x25_asy_change_mtu()
@ 2014-07-17 23:48 ` David Miller
0 siblings, 0 replies; 11+ messages in thread
From: David Miller @ 2014-07-17 23:48 UTC (permalink / raw)
To: dan.carpenter
Cc: teg, dh.herrmann, netdev, eric.dumazet, David.Laight, kernel-janitors
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 17 Jul 2014 13:50:45 +0300
> If "newmtu * 2 + 4" is too large then it can cause an integer overflow
> leading to memory corruption. Eric Dumazet suggests that 65534 is a
> reasonable upper limit.
>
> Btw, "newmtu" is not allowed to be a negative number because of the
> check in dev_set_mtu(), so that's ok.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Cap it at 65534 instead of just testing for integer overflows.
> Thanks David and Eric!
Applied.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-07-17 23:48 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-17 8:03 [patch] wan/x25_asy: integer overflow in x25_asy_change_mtu() Dan Carpenter
2014-07-17 8:03 ` Dan Carpenter
2014-07-17 8:45 ` David Laight
2014-07-17 8:58 ` Dan Carpenter
2014-07-17 8:58 ` Dan Carpenter
2014-07-17 9:14 ` Eric Dumazet
2014-07-17 9:14 ` Eric Dumazet
2014-07-17 10:50 ` [patch v2] " Dan Carpenter
2014-07-17 10:50 ` Dan Carpenter
2014-07-17 23:48 ` David Miller
2014-07-17 23:48 ` David Miller
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.