Bug in gprs decode software

[Dario Lombardo]

Opps... typo...

-if (f->len > li_off && f->len-li_off > 65536) {
+if (f->len > li_off && f->len-li_off < 65536) {

On Fri, Nov 25, 2011 at 11:30 AM, Dario Lombardo
<dario.lombardo at libero.it>wrote:

> Hi guys
> Today I'm experiencing a bug in the gprs decode software. In rlcmac.c:190,
> when li_off and f->len get invalid values, we have a buffer overflow in the
> mempy(). In my case f->len=15, li_off=135.
> The really stupid patch to avoid it is below: simply jumps the case. I'm
> not able to investigate why li_off becames greater than f->len, causing the
> crash. Maybe a check should added.
> Have some other seen this crash?
>
> diff --git a/rlcmac.c b/rlcmac.c
> index eea02ce..d76a8d6 100644
> --- a/rlcmac.c
> +++ b/rlcmac.c
> @@ -187,11 +187,14 @@ void process_blocks(struct gprs_tbf *t, int ul)
>                                         print_pkt(llc_data, llc_len);
>                                         fflush(stdout);
>                                 }
> -                               memcpy(llc_data, &f->data[li_off],
> f->len-li_off);
> -                               llc_len = f->len - li_off;
> -                               llc_first_bsn = bsn;
> -                               llc_last_bsn = bsn;
> -                               t->start_bsn = bsn;
> +
> +                               if (f->len > li_off && f->len-li_off >
> 65536) {
> +                                   memcpy(llc_data, &f->data[li_off],
> f->len-li_off);
> +                                   llc_len = f->len - li_off;
> +                                   llc_first_bsn = bsn;
> +                                   llc_last_bsn = bsn;
> +                                   t->start_bsn = bsn;
> +                               }
>                         }
>
>                 }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111125/95a4bd5a/attachment.html>