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

["Valsecchi Patrick" <patrick.valsecchi@nagra.com>]

Hi,

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).

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

I see two possible actions against that:

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

  2) put in the documentation this behaviour and tell that the user
     space should check the section_syntax_indicator before parsing
     the section.

Warning, 1) is IMHO the best solution, but it may be breaking some
applications that uses this behavior.

CU

-----Original Message-----
From: linux-dvb-bounce@linuxtv.org
To: linux-dvb@linuxtv.org
Sent: 1/6/2005 8:02 PM
Subject: [linux-dvb] Re: Bug in software demux still in 2.6.10

> IMO it should be something like
> if (!ccok && !dc_i)
> because dc_i signals a discontinuity introduced by the transmitting
> multiplexer, such that the assumption of data being lost does not
> hold for this case.
> However, if I understand ISO13818-1 correctly, one should also
> have a look at wether the packet belongs to a PID carrying PCR or
> not.

Right, I should try (!ccok && !dc_i) and see if there's some
noticeable change