All of lore.kernel.org
 help / color / mirror / Atom feed
* Question regarding handling of ootb packets
@ 2010-01-19  2:42 Neil Horman
  2010-01-19  3:23 ` Wei Yongjun
  2010-01-22 12:01 ` Neil Horman
  0 siblings, 2 replies; 3+ messages in thread
From: Neil Horman @ 2010-01-19  2:42 UTC (permalink / raw)
  To: linux-sctp

Hey all-
	I'm having a bit of trouble understanding the implementation of
sctp_rcv_ootb.  Specifically I'm wondering why we allow packets checked in
sctp_rcv_ootb with malformed chunks into the receive queue.  For instance, if a
chunk in an ootb packet has a zero length, we break out of the loop and return
0, which lets us eventually call sctp_inq_push to put it on the receive queue,
from which point on we seem to assume the chunk header length field is valid and
correct.  Am I missing something, or is this a bug?

Thanks!
Neil


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question regarding handling of ootb packets
  2010-01-19  2:42 Question regarding handling of ootb packets Neil Horman
@ 2010-01-19  3:23 ` Wei Yongjun
  2010-01-22 12:01 ` Neil Horman
  1 sibling, 0 replies; 3+ messages in thread
From: Wei Yongjun @ 2010-01-19  3:23 UTC (permalink / raw)
  To: linux-sctp

Neil Horman wrote:
> Hey all-
> 	I'm having a bit of trouble understanding the implementation of
> sctp_rcv_ootb.  Specifically I'm wondering why we allow packets checked in
> sctp_rcv_ootb with malformed chunks into the receive queue.  For instance, if a
> chunk in an ootb packet has a zero length, we break out of the loop and return
> 0, which lets us eventually call sctp_inq_push to put it on the receive queue,
> from which point on we seem to assume the chunk header length field is valid and
> correct.  Am I missing something, or is this a bug?
>
>   

Before we put it to the receive queue, we had confirmed that
this chunk has a lendth at least sizeof(struct sctp_chunkhdr).
  int sctp_rcv(struct sk_buff *skb)
  {
    ...
    /* Make sure we at least have chunk headers worth of data left. */
    if (skb->len < sizeof(struct sctp_chunkhdr))
        goto discard_it;
    ...
  }

We let this chunk go into process by sctp_inq_push() is because
do this we can then send a ABORT to tell the sender the packet
is malformed. the chunk header length check will be done later,
sush as in sctp_sf_ootb().

>   

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question regarding handling of ootb packets
  2010-01-19  2:42 Question regarding handling of ootb packets Neil Horman
  2010-01-19  3:23 ` Wei Yongjun
@ 2010-01-22 12:01 ` Neil Horman
  1 sibling, 0 replies; 3+ messages in thread
From: Neil Horman @ 2010-01-22 12:01 UTC (permalink / raw)
  To: linux-sctp

On Tue, Jan 19, 2010 at 11:23:51AM +0800, Wei Yongjun wrote:
> Neil Horman wrote:
> > Hey all-
> > 	I'm having a bit of trouble understanding the implementation of
> > sctp_rcv_ootb.  Specifically I'm wondering why we allow packets checked in
> > sctp_rcv_ootb with malformed chunks into the receive queue.  For instance, if a
> > chunk in an ootb packet has a zero length, we break out of the loop and return
> > 0, which lets us eventually call sctp_inq_push to put it on the receive queue,
> > from which point on we seem to assume the chunk header length field is valid and
> > correct.  Am I missing something, or is this a bug?
> >
> >   
> 
> Before we put it to the receive queue, we had confirmed that
> this chunk has a lendth at least sizeof(struct sctp_chunkhdr).
>   int sctp_rcv(struct sk_buff *skb)
>   {
>     ...
>     /* Make sure we at least have chunk headers worth of data left. */
>     if (skb->len < sizeof(struct sctp_chunkhdr))
>         goto discard_it;
>     ...
>   }
> 
> We let this chunk go into process by sctp_inq_push() is because
> do this we can then send a ABORT to tell the sender the packet
> is malformed. the chunk header length check will be done later,
> sush as in sctp_sf_ootb().
> 
Got it, thanks Wei!
Neil

> >   
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" 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] 3+ messages in thread

end of thread, other threads:[~2010-01-22 12:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-19  2:42 Question regarding handling of ootb packets Neil Horman
2010-01-19  3:23 ` Wei Yongjun
2010-01-22 12:01 ` Neil Horman

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.