[linux-dvb] Re: Bug in software demux still in 2.6.10

[Johannes Stezenbach <js@linuxtv.org>]

Valsecchi Patrick wrote:
> I found another risk of feeding corruped sections to a unknowing
> userspace application. This time, it's not in the
> de-packetization anymore, but in the CRC checking.
> 
> Here is the scenario:
>   - A userspace soft opens a demux and set the filters for one PID
>     with CRC checking. For example for listening to PAT sections.
>   - You have some noise on the feed and the noise happens to be on
>     the second byte of the section (with more corrupted bytes
>     possible), just where the section_syntax_indicator flag lies.
>   - Since the dvb_dmx_swfilter_section_feed function doesn't check
>     the CRC when that flag is not set, the corrupted section is sent
>     to the user space which takes for granted that the CRC is checked
>     (used to be the case in my application).

I don't remember why this was implemented that way, but IMHO this
behaviour is buggy, as e.g. the TOT has ssi 0 but still a CRC.
I vaguely remember that the problem was that some software
always set the CHECK_CRC flag, which "worked" with the old
dvb-ttpci driver because the av7110 firmware does not check
the CRC at all (!). When we changed to dvb-ttpci driver to
use the software demux some things ceased to work...

> In my experiencem corruptions is always located when it will cause the
> biggest problems  ;-)

Sure, but userspace must not rely on getting consistent data anyway, I've
seen plenty section with perfectly valid CRC that contained total crap.
See the thread about KaxTV tripping over broken EITs.

>   1) if the userspace asks for CRC checking and the
>      section_syntax_indicator is not set; then reject the section.

Don't work for TOT.

IMHO the CRC should be checked when the user wants it, regardless
of what the ssi says. OTOH I know that some popular STB hardware
implements CRC only for ssi=1...

Anyway, maybe the software demux should simply drop TS packets with
the transport_error_indicator set. That would avoid your
original problem with corruption in the wrong place. It's also
what hardware section filters normally do.

Johannes