[IrDA]: Frame length validation.

When using a stir4200-based USB adaptor to talk to a device that uses
an mcp2150, the stir4200 sometimes drops an incoming frame causing the
mcp2150 to try and retransmit the lost frame. In this combination, the
next frame received from the mcp2150 is often invalid - either an
empty i:rsp or an IrCOMM i:rsp with an invalid clen. These corner
cases are now checked.

Signed-off-by: Robie Basak <rb-oss-1@justgohome.co.uk>
Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 12 insertions, 0 deletions

diff --git a/net/irda/ircomm/ircomm_core.c b/net/irda/ircomm/ircomm_core.c
index 2d63fa8e1556..b825399fc160 100644
--- a/net/irda/ircomm/ircomm_core.c
+++ b/net/irda/ircomm/ircomm_core.c
@@ -363,6 +363,18 @@ void ircomm_process_data(struct ircomm_cb *self, struct sk_buff *skb)
         clen = skb->data[0];
 
         /*
+         * Input validation check: a stir4200/mcp2150 combinations sometimes
+         * results in frames with clen > remaining packet size. These are
+         * illegal; if we throw away just this frame then it seems to carry on
+         * fine
+         */
+        if (unlikely(skb->len < (clen + 1))) {
+                IRDA_DEBUG(2, "%s() throwing away illegal frame\n",
+                           __FUNCTION__ );
+                return;
+        }
+
+        /*
          * If there are any data hiding in the control channel, we must
          * deliver it first. The side effect is that the control channel
          * will be removed from the skb