In message <[EMAIL PROTECTED]>, Tetsuo Handa writes: > Hello. > > I noticed that the below sequence triggers NULL pointer dereference > if copyup_dentry() failed by some reason (e.g. mandatory access control). > / (which contains /tmp/ ) partition is an ext3 filesystem. > > [EMAIL PROTECTED] ~]# ls -l /tmp/1/ /tmp/2/ > /tmp/1/: > total 0 > > /tmp/2/: > total 0 > [EMAIL PROTECTED] ~]# touch /tmp/2/foo > [EMAIL PROTECTED] ~]# mount -t unionfs -o dirs=/tmp/1=rw:/tmp/2=ro none /mnt/ > [EMAIL PROTECTED] ~]# touch /mnt/foo > > The below dmesg is obtained by "touch /mnt/foo" > with permission to open() /mnt/foo for writing > and without permission to call chmod()/chown(), > using unionfs-2.3.3_for_2.6.24.5 with the printk() patch applied. [...] > EIP: [<e08780ec>] unionfs_setattr+0x324/0x35b [unionfs] SS:ESP 0068:defbce5c [...]
Dear Tetsuo, Was this a vanilla 2.6.24.5 kernel, or did it have other patches applied? In particular, are you using any "special" MAC system or the like, ala selinux, smack, etc.? I'd like to be able to reproduce this on my end. Since you were able to stick printk's in unionfs_setattr, can you add a few more closer to the end (0x324/0x35b) and try to narrow down where's the null deref? In the steps above: it looks fairly simple (ie. no funky chroot, bind mounts, pivot_root, etc.) right? Do you know what's the condition which caused copyup_dentry (in unionfs_setattr) to fail? Can you print the errno? If you don't mind, please open a bugzilla report at https://bugzilla.filesystems.org/, give me pointers to any patches you applied to the kernel, kernel .config used, etc. BTW, does the problem still exist in unionfs-2.4? Thanks, Erez. _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
