Rainer Zocholl writes: > [EMAIL PROTECTED](Ralph Metzler) 17.10.01 03:33 > >I think VDR uses the DVR device but in this case the copy routines > >are really simple and I don't know what could go wrong there. > > I saw in all Oopses, that it was in a "rep mov" operation. > Always "EDI" (Destination) is at xxxxxFFF, meaning that a page > wrap (maybe 64k wrap?) will occure in the next "mov" operation. > "ECX" (amount) alwys have still big values >> 4k to copy left.
Hmm, such big moves should not occur. So, it is probably some underflow of a length variable. I found one place in the source where this could happen if data is corrupted and check for it now. > >If section filters are used at the same time the problem is more > >likely to be in the section filter routines in dvb_demux.c. > >I tried to write them in such a way that they don't cause > >overflows even if the data is corrupt but there still could be > >bugs in there. > > I doubled the 4096 buffer because on one place > "3+" (inline section_len) is counted. I got no oopses, but VDR complaints about > bad data. But "oopses" are real seldom. (Once in an hour or day..) > > > dvb_demux.h: u8 secbuf[4096]; > dvb_demux.h: u8 secbuf[2*4096]; > > dvb_demux.c: section_length(const u8 *buf) > dvb_demux.c: return 3+((buf[1]&0x0f)<<8)+buf[2]; > > I did not analayze the code in deep, but section_length > can become "4096+3". It should't (according to DVB specs) but it can of course happen if the signal quality is bad and the data is corrupted. I added checks for this and another possible source of buffer overflows (as mentioned above) to the current CVS. I hope I have all of them covered now. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
