[Unionfs] NULL pointer dereference if copyup_dentry() failed?

[Erez Zadok]

In message <200807112259.GIB81720.FMHFOtOLFJVOSQ at I-love.SAKURA.ne.jp>, 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.
> 
> [root at tomoyo ~]# ls -l /tmp/1/ /tmp/2/
> /tmp/1/:
> total 0
> 
> /tmp/2/:
> total 0
> [root at tomoyo ~]# touch /tmp/2/foo
> [root at tomoyo ~]# mount -t unionfs -o dirs=/tmp/1=rw:/tmp/2=ro none /mnt/
> [root at tomoyo ~]# 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.