aufs calls security_path_mknod with a wrong parameter

The security_path_mknod() call expects the 'dev' argument to be in encoded form instead of its decode dev conversion. However aufs is calling it with a 'dev' parameter that has already been converted with new_decode_dev().

as can be seen from fs/namei.c security_path_mknod is called correctly, and vfs_mknod is called with new_decode_dev(dev)
2016 error = security_path_mknod(&nd.path, dentry, mode, dev);
2017 if (error)
2018 goto out_drop_write;
2019 switch (mode& S_IFMT) {
2020 case 0: case S_IFREG:
2021 error = vfs_create(nd.path.dentry->d_inode,dentry,mode,&nd);
2022 break;
2023 case S_IFCHR: case S_IFBLK:
2024 error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,
2025 new_decode_dev(dev));

But aufs's vfsub_mknod() (called from add_simple() from aufs_mknod() from
vfs_mknod()) is calling security_path_mknod().

  266 int vfsub_mknod(struct inode *dir, struct path *path, int mode, dev_t dev)
  267 {
  268 int err;
  269 struct dentry *d;
  270
  271 IMustLock(dir);
  272
  273 d = path->dentry;
  274 path->dentry = d->d_parent;
  275 err = security_path_mknod(path, d, mode, dev);
  276 path->dentry = d;
  277 if (unlikely(err))
  278 goto out;
  279
  280 err = vfs_mknod(dir, path->dentry, mode, dev);

In vfsub_mknod(), 'dev' was already converted by 'new_decode_dev(dev)'
but the LSM and the TOMOYO security module is expecting 'dev' rather than 'new_decode_dev(dev)'.

With Natty kernel, TOMOYO will check new_decode_dev(new_decode_dev(dev)) (which is wrong) when invoked via the security_path_mknod() call from aufs.