vdr-1.3.23: BUG: cPesAssembler dropped data resulting in delayed crash of VDR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



rnissl@xxxxxx(Reinhard Nissl)  01.05.05 23:39


>Hi,

>while recording the radio channel "Bayern 1" on Astra 19.2E from 0900
>to 1000 this morning, I've discoverd that VDR crashed at about 0932.

>After debugging the whole afternoon I've recently found the bug that
>caused this crash. It's cPesAssembler that drops some data in certain
>circumstances. The crash has nothing todo with recording this channel,
>but with the transfer mode I'm using with vdr-xine, as it makes use of
>cPesAssembler.

>BTW: To reproduce this crash just tune to the mentioned channel in
>transfer mode and wait for about 33 minutes.

>The bug has to do with cPesAssembler's length member, as it conforms
>to this equation:

>	length == 0 || length >=4

>It's therefore impossible for cPesAssembler to store any fragments of
>less than 4 bytes. But the problem is, that these bytes have modified
>it's shift register "tag" which leads to wrong synchronisation on the
>next fragment.

>For this channel, it seems to happen that cPesAssembler sees data
>blocks that end with the sequence 00 00 01. These 3 bytes are stored
>in cPesAssembler's "tag" member. But when the next data block arrives,
>these bytes are ignored, as "length" is still 0, and further data is
>dropped, as it needs to sychronize on the next start code (00 00 01).

>When the next fragment is to be stored, it results in "data" beeing
>something like that

>	00 00 01 00 00 01 c0 ...

>As a result, the expected length evaluates to 6 bytes, but "length"
>containes already more than that (in the above case it was 79). This
>finally leads to "Rest" beeing -73 which then causes a crash in
>memcpy.


Nice bug, nice analysis.

but that leds to a general question:
Why are "foreign"-based parameters to memcpy not range checked?
Nobody should trust any parameters he got from "outside",
we learned in grammar school.

Such "out of range" writings might cause very funny, 
hard to debug errors. Mostly not so "lulely" crashes the
box so reproducible.

Are there maybe more place where "memcpy" and similar critical
("buffer overflow sensitive") function are used with maybe "tainted"
unchecked values, which assumes that all previous calculations are 
done right and all parameters "mets" the specs?



Rainer



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux