Re: CVE-2010-1173 kernel: skb_over_panic resulting from multiple invalid parameter errors

[Hui Zhu <hui.zhu () windriver com>]

Eugene Teo:
> https://bugzilla.redhat.com/CVE-2010-1173
> http://article.gmane.org/gmane.linux.network/159531
>
> Reported by Chris Guo from Nokia China via Red Hat Support. A similar
> issue was reported by Jukka Taimisto and Olli Jarva from Codenomicon Ltd
> via CERT-FI. This was also reported by Windriver on behalf of their
> customer via vendor-sec.
>
> Kernel crash occurs if sctp listening port receives malformatted init
> package.
>
> Its an skb_over_panic BUG halt that results from processing an init
> chunk in which too many of its variable length parameters are in some
> way malformed.
>
> The problem is in sctp_process_unk_param:
> if (NULL == *errp)
>  *errp = sctp_make_op_error_space(asoc, chunk,
>       ntohs(chunk->chunk_hdr->length));
>
>  if (*errp) {
>   sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
>      WORD_ROUND(ntohs(param.p->length)));
>   sctp_addto_chunk(*errp,
>    WORD_ROUND(ntohs(param.p->length)),
>       param.v);
>
> When we allocate an error chunk, we assume that the worst case scenario
> requires that we have chunk_hdr->length data allocated, which would be
> correct nominally, given that we call sctp_addto_chunk for the violating
> parameter. Unfortunately, we also, in sctp_init_cause insert a
> sctp_errhdr_t structure into the error chunk, so the worst case
> situation in which all parameters are in violation requires
> chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.
>
> This fix solves the problem by allowing our implementation to only
> report a fixed number of errors.  When we encounter an error in
> parameter processing we allocate a chunk that is min(asoc->pathmtu,
> SCTP_DEFAULT_MAXSEGMENT), limiting our error reporting to a single mtu
> sized chunk.  Parameter errors that grow beyond that value are discarded.
>
> Thanks, Eugene

Add Xiao to CC list.

Hui