Dear sirs, On Sep 28 2007, [EMAIL PROTECTED] wrote: > Please include the line below in follow-up emails for this request. > > Follow-up: 31431748 > > Hello Prof. Rogério Brito, > > Our engineers have evaluated this issue and determine that the value > at -1 offset of srcOffs is a valid value in the buffer which is the > offset to free space in the node.
I don't exactly see why this is a legal value. It doesn't seem to be. At least, I get problems when running fsck_hfs on a Linux platform running at 64 bits. > srcOffs is a uint16_t pointer which is initialized to point at offset > of last record offset in the buffer that contains the catalog btree > node. Tracing the program doesn't seem to indicate that srcOffs is initialized when the index is -1, which is accessed in the first iteration near line 519. Here is the (lengthy) output of a call to fsck_hfs under a diagnostic tool called Valgrind that exposes exactly the problem that I see. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [EMAIL PROTECTED]:/tmp/hfsprogs-332.14/fsck_hfs.tproj$ ./fsck_hfs /tmp/disk.img ** /tmp/disk.img ** Checking HFS Plus volume. Segmentation fault [EMAIL PROTECTED]:/tmp/hfsprogs-332.14/fsck_hfs.tproj$ valgrind ./fsck_hfs /tmp/disk.img ==17816== Memcheck, a memory error detector. ==17816== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==17816== Using LibVEX rev 1804, a library for dynamic binary translation. ==17816== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==17816== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==17816== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==17816== For more details, rerun with: -v ==17816== ** /tmp/disk.img ** Checking HFS Plus volume. ==17816== Invalid read of size 2 ==17816== at 0x41F6AC: hfs_swap_HFSPlusBTInternalNode (hfs_endian.c:519) ==17816== by 0x41EE32: hfs_swap_BTNode (hfs_endian.c:305) ==17816== by 0x424E1B: GetNode (BTreeNodeOps.c:147) ==17816== by 0x4260B1: SearchTree (BTreeTreeOps.c:231) ==17816== by 0x4220D3: BTSearchRecord (BTree.c:761) ==17816== by 0x42BAAD: SearchBTreeRecord (SBTree.c:83) ==17816== by 0x4072FF: CreateCatalogBTreeControlBlock (SVerify1.c:1148) ==17816== by 0x4043E4: ScavCtrl (SControl.c:393) ==17816== by 0x403DFD: CheckHFS (SControl.c:145) ==17816== by 0x401987: checkfilesys (fsck_hfs.c:297) ==17816== by 0x40177D: main (fsck_hfs.c:191) ==17816== Address 0x20557effa is not stack'd, malloc'd or (recently) free'd ==17816== ==17816== Process terminating with default action of signal 11 (SIGSEGV) ==17816== Access not within mapped region at address 0x20557EFFA ==17816== at 0x41F6AC: hfs_swap_HFSPlusBTInternalNode (hfs_endian.c:519) ==17816== by 0x41EE32: hfs_swap_BTNode (hfs_endian.c:305) ==17816== by 0x424E1B: GetNode (BTreeNodeOps.c:147) ==17816== by 0x4260B1: SearchTree (BTreeTreeOps.c:231) ==17816== by 0x4220D3: BTSearchRecord (BTree.c:761) ==17816== by 0x42BAAD: SearchBTreeRecord (SBTree.c:83) ==17816== by 0x4072FF: CreateCatalogBTreeControlBlock (SVerify1.c:1148) ==17816== by 0x4043E4: ScavCtrl (SControl.c:393) ==17816== by 0x403DFD: CheckHFS (SControl.c:145) ==17816== by 0x401987: checkfilesys (fsck_hfs.c:297) ==17816== by 0x40177D: main (fsck_hfs.c:191) ==17816== ==17816== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1) ==17816== malloc/free: in use at exit: 130,862 bytes in 15 blocks. ==17816== malloc/free: 16 allocs, 1 frees, 130,877 bytes allocated. ==17816== For counts of detected errors, rerun with: -v ==17816== searching for pointers to 15 not-freed blocks. ==17816== checked 4,433,224 bytes. ==17816== ==17816== LEAK SUMMARY: ==17816== definitely lost: 0 bytes in 0 blocks. ==17816== possibly lost: 0 bytes in 0 blocks. ==17816== still reachable: 130,862 bytes in 15 blocks. ==17816== suppressed: 0 bytes in 0 blocks. ==17816== Rerun with --leak-check=full to see details of leaked memory. Segmentation fault [EMAIL PROTECTED]:/tmp/hfsprogs-332.14/fsck_hfs.tproj$ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I can provide more details, if necessary. > However, we are concerned about the segmentation fault you are > encountering and would like to debug it further. I hope that the output above helps you with your task. Oh, while I am at it, I would like to integrate some patches of mine in your development tree (since, I suppose, you're serious in the Open Source development). Since I have read the code, I obviously encountered some points that are considered bad practices and I would love to contribute to have better tools and actually use more HFS+ filesystems under Linux too as a good way of sharing data between platforms. > Can you provide us with steps to reproduce the issue? An image of the > filesystem that causes the crash would also be helpful. It is incredibly simple to reproduce the issue under Linux with the source code provided in diskdev_cmds-322.x: $ dd if=/dev/zero of=/tmp/disk.img bs=1M count=100 $ mkfs_hfs /tmp/disk.img $ fsck_hfs /tmp/disk.img These steps are simple enough to reproduce the segmentation fault in the package (they were actually what I used on my system). > Thanks in advance, > Apple Product Security team Regards, -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
