Hi all, I received a very good bug report from Radek Pospisil about a problem he had with mkisofs. He used it together with my root patch for backup purposes, but the same problem can be triggered with the unpatched mkisofs from cdrtools 2.01a23.
If an incremental backup was made where one of the directories in the existing ISO image had an odd name length between 111 and 135, then the mkisofs invocation that scans that image hangs. It is important that -graft-points is used on that long directory name, something that the new -root option does implicitly. Here's how this can be reproduced with cdrtools 2.01a23: [EMAIL PROTECTED](/tmp)$ mkdir 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 [EMAIL PROTECTED](/tmp)$ /usr/local/cdrtools-2.01/mkisofs/OBJ/i686-linux-cc/mkisofs -R -o 1.iso -graft-points 1/12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345=12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 [EMAIL PROTECTED](/tmp)$ ll 1.iso -rw-r--r-- 1 patrick patrick 364544 Jan 6 20:31 1.iso [EMAIL PROTECTED](/tmp)$ /usr/local/cdrtools-2.01/mkisofs/OBJ/i686-linux-cc/mkisofs -R -o 2.iso -M 1.iso -C 0,364544 /dev/null Rock Ridge signatures found At this point mkisofs hangs and must be aborted. Here's the content of the image that causes the problem: [EMAIL PROTECTED](~)# mount -o loop /tmp/1.iso /mnt [EMAIL PROTECTED](~)# ll /mnt/ total 2 dr-xr-xr-x 3 patrick patrick 2048 Jan 6 20:31 1 [EMAIL PROTECTED](~)# ll /mnt/1 total 2 dr-xr-xr-x 2 patrick patrick 2048 Jan 6 20:31 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 valgrind on Linux reports two invalid memory reads of the same byte, which happens to be len -= pnt[2]; pnt += pnt[2]; in a while loop that is not properly guarded against reading past the end of the string (see attached diff). In this case, len is 1 when the loop is entered once more, but then pnt[2] is invalid and just happens to be zero, leading to an invinite loop. Unless I have misinterpreted the valgrind output "Address 0x415545D9 is 1 bytes after a block of size 164", the string that is parsed is this: (gdb) x/166cb 0x415545D9-165 0x41554534: 82 'R' 82 'R' 5 '\005' 1 '\001' -119 '\211' 78 'N' 77 'M' -126 '\202' 0x4155453c: 1 '\001' 0 '\0' 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 0x41554544: 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 0x4155454c: 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 0x41554554: 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 0x4155455c: 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 0x41554564: 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 0x4155456c: 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 0x41554574: 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 0x4155457c: 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 0x41554584: 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 0x4155458c: 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 0x41554594: 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 0x4155459c: 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 49 '1' 50 '2' 0x415545a4: 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 0x415545ac: 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 0x415545b4: 57 '9' 48 '0' 49 '1' 50 '2' 51 '3' 52 '4' 53 '5' 67 'C' 0x415545bc: 69 'E' 28 '\034' 1 '\001' 25 '\031' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0x415545c4: 0 '\0' 0 '\0' 25 '\031' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0x415545cc: 0 '\0' 0 '\0' 0 '\0' 62 '>' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0x415545d4: 0 '\0' 0 '\0' 62 '>' 0 '\0' 0 '\0' 0 '\0' Question to someone with more knowledge about ISO9660/RR: is mkisofs generating an invalid image when invoked as described above, or is the ISO parsing code insufficient? In the later case the attached diff should be sufficient to fix the problem. The patch follows the example given at another place where parse_xa() is also called, but then followed by a while loop that tests against 3. It looks like a sane value because it is large enough to ensure that at least two flag bytes and the length in pnt[2] are valid. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]