[PATCH 2/4] [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.

[PATCH 2/4] [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.

[Sridhar Samudrala]

[SCTP]: Prevent possible infinite recursion with multiple bundled DATA.

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>

---

 net/sctp/ulpqueue.c |   27 +++++++++++++++++++++++++--
 1 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 2080b2d..9505c88 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -279,6 +279,7 @@ static inline void sctp_ulpq_store_reasm
 static struct sctp_ulpevent *sctp_make_reassembled_event(struct sk_buff_head *queue, struct sk_buff *f_frag, struct sk_buff *l_frag)
 {
 	struct sk_buff *pos;
+	struct sk_buff *new = NULL;
 	struct sctp_ulpevent *event;
 	struct sk_buff *pnext, *last;
 	struct sk_buff *list = skb_shinfo(f_frag)->frag_list;
@@ -297,11 +298,33 @@ static struct sctp_ulpevent *sctp_make_r
 	 */
 	if (last)
 		last->next = pos;
-	else
-		skb_shinfo(f_frag)->frag_list = pos;
+ 	else {
+ 		if (skb_cloned(f_frag)) {
+ 			/* This is a cloned skb, we can't just modify
+ 			 * the frag_list.  We need a new skb to do that.
+ 			 * Instead of calling skb_unshare(), we'll do it
+ 			 * ourselves since we need to delay the free.
+ 			 */
+ 			new = skb_copy(f_frag, GFP_ATOMIC);
+ 			if (!new)
+ 				return NULL;	/* try again later */
+ 
+ 			new->sk = f_frag->sk;
+ 
+ 			skb_shinfo(new)->frag_list = pos;
+ 		} else
+ 			skb_shinfo(f_frag)->frag_list = pos;
+ 	}
 
 	/* Remove the first fragment from the reassembly queue.  */
 	__skb_unlink(f_frag, queue);
+ 
+ 	/* if we did unshare, then free the old skb and re-assign */
+ 	if (new) {
+ 		kfree_skb(f_frag);
+ 		f_frag = new;
+ 	}
+ 
 	while (pos) {
 
 		pnext = pos->next;

Re: [PATCH 2/4] [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.

[David S. Miller]

From: Sridhar Samudrala <sri@us.ibm.com>
Date: Fri, 05 May 2006 12:14:38 -0700

> [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.
> 
> There is a rare situation that causes lksctp to go into infinite recursion
> and crash the system.  The trigger is a packet that contains at least the
> first two DATA fragments of a message bundled together. The recursion is
> triggered when the user data buffer is smaller that the full data message.
> The problem is that we clone the skb for every fragment in the message.
> When reassembling the full message, we try to link skbs from the "first
> fragment" clone using the frag_list. However, since the frag_list is shared
> between two clones in this rare situation, we end up setting the frag_list
> pointer of the second fragment to point to itself.  This causes
> sctp_skb_pull() to potentially recurse indefinitely.
> 
> Proposed solution is to make a copy of the skb when attempting to link
> things using frag_list.
> 
> Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>

Applied, but again I had to manually remove a ton of trailing
whitespace added by this patch.