diff mbox series

hdlc_ppp: add range checks in ppp_cp_parse_cr()

Message ID 20200908175359.GA356675@mwanda
State New
Headers show
Series hdlc_ppp: add range checks in ppp_cp_parse_cr() | expand

Commit Message

Dan Carpenter Sept. 8, 2020, 5:53 p.m. UTC
There were two bugs here:
1) If opt[1] is zero then this results in a forever loop.  If the value
   is less than 2 then it is invalid.
2) We assume that "len" is more than sizeof(valid_accm) or 6 which can
   result in memory corruption.

Reported-by: ChenNan Of Chaitin Security Research Lab  <whutchennan@gmail.com>
Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic HDLC.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
This was sent to the security list, but we normally just handle
networking driver bugs through the regular netdev list.

 drivers/net/wan/hdlc_ppp.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

Comments

Dan Carpenter Sept. 9, 2020, 7:19 a.m. UTC | #1
On Wed, Sep 09, 2020 at 05:37:37AM +0800, nan chen wrote:
> Looks like the judgment of len <sizeof(valid_accm) has a problem.
> The judgment cannot avoid the memory overflow of the memcpy below.
>                         case LCP_OPTION_ACCM: /* async control character
> map */
> +                               if (len < sizeof(valid_accm))
> +                                       goto err_out;
> Assume that the initial value of len is 10.Then the length of 'out' memory
> is 10.
> And assume the value of opt[1] in each loop is 2.
> Then it will loop 3 times.
> 3 times memcpy will cause the 'out' memory to be overwritten by 18 bytes (
> > 10 bytes). This will be memory overflow.
> 
> I think the correct way is to judge the value of opt[1] like this:
> .                        case LCP_OPTION_ACCM: /* async control character
> map */
> +                               if (opt[1] < sizeof(valid_accm))
> +                                       goto err_out;
> 

Yeah.  You're right.  The "nak_len" count would grow faster than it
should leading to memory corruption.  I'll resend.

regards,
dan carpenter
diff mbox series

Patch

diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 48ced3912576..4e906b79a85f 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -383,11 +383,8 @@  static void ppp_cp_parse_cr(struct net_device *dev, u16 pid, u8 id,
 	}
 
 	for (opt = data; len; len -= opt[1], opt += opt[1]) {
-		if (len < 2 || len < opt[1]) {
-			dev->stats.rx_errors++;
-			kfree(out);
-			return; /* bad packet, drop silently */
-		}
+		if (len < 2 || opt[1] < 2 || len < opt[1])
+			goto err_out;
 
 		if (pid == PID_LCP)
 			switch (opt[0]) {
@@ -395,6 +392,8 @@  static void ppp_cp_parse_cr(struct net_device *dev, u16 pid, u8 id,
 				continue; /* MRU always OK and > 1500 bytes? */
 
 			case LCP_OPTION_ACCM: /* async control character map */
+				if (len < sizeof(valid_accm))
+					goto err_out;
 				if (!memcmp(opt, valid_accm,
 					    sizeof(valid_accm)))
 					continue;
@@ -406,6 +405,8 @@  static void ppp_cp_parse_cr(struct net_device *dev, u16 pid, u8 id,
 				}
 				break;
 			case LCP_OPTION_MAGIC:
+				if (len < 6)
+					goto err_out;
 				if (opt[1] != 6 || (!opt[2] && !opt[3] &&
 						    !opt[4] && !opt[5]))
 					break; /* reject invalid magic number */
@@ -424,6 +425,11 @@  static void ppp_cp_parse_cr(struct net_device *dev, u16 pid, u8 id,
 		ppp_cp_event(dev, pid, RCR_GOOD, CP_CONF_ACK, id, req_len, data);
 
 	kfree(out);
+	return;
+
+err_out:
+	dev->stats.rx_errors++;
+	kfree(out);
 }
 
 static int ppp_rx(struct sk_buff *skb)