From patchwork Mon Jan 19 09:44:18 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexw X-Patchwork-Id: 12698 Received: from 159.a2c-250-154.astra2connect.com ([92.250.154.159] helo=undercover.mine.nu) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from ) id 1LOqh7-0003dJ-7N for vdr@linuxtv.org; Mon, 19 Jan 2009 10:45:23 +0100 Received: from anubis.localnet ([212.56.227.241]) (authenticated bits=0) by undercover.mine.nu (8.14.3/8.14.3) with ESMTP id n0J9iJf7018447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 10:44:27 +0100 From: Alexw To: Klaus Schmidinger , vdr@linuxtv.org Date: Mon, 19 Jan 2009 10:44:18 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-134.fc10.i686; KDE/4.1.3; i686; ; ) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901191044.18786.alexw@undercover.mine.nu> X-LSpam-Score: -2.4 (--) X-LSpam-Report: No, score=-2.4 required=5.0 tests=AWL=0.173, BAYES_00=-2.599 autolearn=ham Subject: [vdr] PMT in multiple TS packet bug X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:45:24 -0000 Status: O X-Status: X-Keywords: X-UID: 19261 Hi Klaus, I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults. First I found out that 2 lines where added in the ParsePmt method. Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; At the moment I don't know exactly what is the meaning of this 2 operations. The second line can result in a negative Length which is the reason of the segfault. Could you kindly explain the offset drift? In a single section PMT (99.9% of the time) Data[0] is always equal to 0 and we skip the first byte. Length is reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to skip more than a section is not possible in the actual context. I have done a quick and dirty hack to prevent the segfault: the second step will be to have the parsing of multiple section allowed. At the moment when the data size exceed the section size (max 4096), PMT cannot be parsed. [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: PMT section length too big (4176 byte)! [2222] ERROR: can't parse PMT Regards, Alex --- remux.c_ori 2009-01-16 21:05:46.000000000 +0100 +++ remux.c 2009-01-17 13:34:17.000000000 +0100 @@ -361,6 +361,7 @@ if (pmtSize == 0) { Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; + if ( Length < 0 ) Length = 0; if (SectionLength(Data, Length) > Length) { if (Length <= int(sizeof(pmt))) { memcpy(pmt, Data, Length);