[PATCH review 4/4] vfs: Do not allow escaping from bind mounts.

Jann Horn jann at thejh.net
Thu Apr 9 13:06:01 UTC 2015


On Wed, Apr 08, 2015 at 06:34:12PM -0500, Eric W. Biederman wrote:
> +static unsigned d_depth(const struct dentry *dentry)
> +{
> +	unsigned depth = 0;
> +
> +	while (!IS_ROOT(dentry)) {
> +		dentry = dentry->d_parent;
> +		depth++;
> +	}
> +	return depth;
> +}

This relies on a depth of 2^32 being impossible, right? Which is guaranteed
somewhat because you would need something like a terabyte of RAM to have
that many dentries in RAM? I can't find any explicit check. Maybe it would
make sense to let the depth be 64 bits or add some kind of overflow check?
Or did I just miss some kind of check on allocation?

<https://access.redhat.com/articles/rhel-limits> claims that redhat has
tested RHEL on a machine with 6TB of physical RAM. I think that 2^32
dentries would fit in there.


> +static const struct dentry *d_common_ancestor(const struct dentry *left,
> +					      const struct dentry *right)
> +{
> +	unsigned ldepth = d_depth(left);
> +	unsigned rdepth = d_depth(right);
> +
> +	if (ldepth > rdepth) {
> +		swap(left, right);
> +		swap(ldepth, rdepth);
> +	}
> +
> +	while (rdepth > ldepth) {
> +		right = right->d_parent;
> +		rdepth--;
> +	}

At this point, the actual depths could differ by 2^32,
right?


> +	while (right != left) {
> +		if (IS_ROOT(right))
> +			return NULL;
> +		right = right->d_parent;
> +		left = left->d_parent;

And then one of these could crash with a NULL pointer deref?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/containers/attachments/20150409/21a5e07e/attachment.sig>


More information about the Containers mailing list