[vdr 2.4.6] ERROR: buffer overflow in cCaPidReceiver::Receive()

  • Code
    1. Jan 21 16:21:19 vdr01 vdr[7700]: [10098] ERROR: buffer overflow in cCaPidReceiver::Receive()

    Hab ich zufällig im Log gefunden. Das ganze ist beim Zappen über mehrere verschlüsselte Kanäle passiert, die nicht entschlüsselt werden.

    Im Betrieb ist mir nichts weiter aufgefallen.


    Hier ein Ausschnitt des Logs zu dem Zeitpunkt:

    Picon.cz2VDR (Kanallogos) - Picons2VDR (Kanallogos) - MP-Logos (Kanallogos) - MV_Backup (Backup mit RSync) - MV_BorgBackup (Backup mit Borg) - Skin FlatPlus (Fork)

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde." [Ken Olson], Präsident der Digital Equipment Corp., 1977

  • OK. Werd ich machen

    Picon.cz2VDR (Kanallogos) - Picons2VDR (Kanallogos) - MP-Logos (Kanallogos) - MV_Backup (Backup mit RSync) - MV_BorgBackup (Backup mit Borg) - Skin FlatPlus (Fork)

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde." [Ken Olson], Präsident der Digital Equipment Corp., 1977

  • Wäre interessant eine Warnung auszugeben, falls in ci.c:191 length > 1024. (oder buffer auf 4096 bytes zu vergrößern)

  • In Zeile 121 heißt es, dass die CAT maximal 1024 Byte lang sein kann. Den Buffer zu vergrößern halte ich daher nicht für sinnvoll, da es ein eventuelles Problem wohl eher verschleiern würde.


    Die Warnung fallls length > 1024 ist (da die Section-Length ja 12 Bit hat) wäre dagegen sicher sinnvoll.

    MegaV0lt : magst du das mal testweise bei dir einbauen und versuchen, den Fall erneut zu forcieren?

  • Die en-13818-1 sagt an der Stelle, dass section_length maximal 1021 bzw 0x3FD sein 'soll', aber eine Compliance zur Spec nicht gefordert wird.

  • Diff
    1. --- ci.c.orig 2021-01-22 16:00:21.403430549 +0100
    2. +++ ci.c 2021-01-22 16:02:32.406932688 +0100
    3. @@ -189,6 +189,7 @@
    4. if (TsPayloadStart(Data)) {
    5. if (Data[5] == SI::TableIdCAT) {
    6. length = (int(Data[6] & 0x0F) << 8) | Data[7]; // section length (12 bit field)
    7. + if (length > 0x3FD) esyslog("ERROR: UNEXPECTED: CAT section_length = %d", length);
    8. if (length > 5) {
    9. int v = (Data[10] & 0x3E) >> 1; // version number
    10. if (v != catVersion) {
  • Ob es nicht einfach nur ein Datenfeher war? Ich habe die aktuelle CAT auf 12090V (TRACE URBAN / SID 9414) als Hexdump.

    Sie ist 221 Bytes gross.

    LG Helmut

  • kls

    Mach ich gerne. Allerdings geht das erst wieder ab Montag. Wenn es hilft, kann ich auch den 2.5.1er VDR drauf machen...


    PS: Datenfehler kann schon sein. Passiert beim durchprobieren / Zappen

    Picon.cz2VDR (Kanallogos) - Picons2VDR (Kanallogos) - MP-Logos (Kanallogos) - MV_Backup (Backup mit RSync) - MV_BorgBackup (Backup mit Borg) - Skin FlatPlus (Fork)

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde." [Ken Olson], Präsident der Digital Equipment Corp., 1977

  • Möglicherweise war ein unerwartetes 'PayLoadStart' mit einer noch unvollständigie Multi-Packet CAT die Ursache.

    Wenn hier nun ein Paket mit 'PayLoadStart' eintrifft, wird 'length' wieder auf die CAT-Gesamtlänge gesetzt, 'pbuf' bleibt aber - bei gleicher 'catVersion' - unverändert. Das Ganze läuft dann asynchron weiter - das 2. Paket schiebt 'pbuf* weiter, 'length' wird dabei aber nicht 0. Dann wieder das 1. Paket, ändert nur 'length' usw. Nach ein paar Durchäufen ist der Buffer voll.

    Mit MTD wird außerdem nur diese unvollständige CAT an das CAM übertragen.


    Hier ein Patch, der diesen Fehler verhindern sollte:

    Da ich Multi-packet CATs nur bei französischen (CSAT) und spanischen Providern gesehen habe, wird sich die ordnungsgemässe Funktion aber gar nicht so leicht feststellen lassen.
    LG Helmut

  • Hab jetzt den VDR 2.51 mit dem Patch vdr-2.4.6-fix-incomplete-multipacket-cat.patch drauf. Bis jetzt konnte ich die Meldung nicht mehr Provozieren...

    Picon.cz2VDR (Kanallogos) - Picons2VDR (Kanallogos) - MP-Logos (Kanallogos) - MV_Backup (Backup mit RSync) - MV_BorgBackup (Backup mit Borg) - Skin FlatPlus (Fork)

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde." [Ken Olson], Präsident der Digital Equipment Corp., 1977