This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Dario Lombardo dario.lombardo at libero.itHi 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/7888bb90/attachment.htm>