Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

On Wed, Oct 10, 2018 at 02:37:28AM +1100, Aleksa Sarai wrote:

quoted

quoted

+static inline int nd_alloc_dpathbuf(struct nameidata *nd)
+{
+       if (unlikely(!nd->dpathbuf)) {
+               if (nd->flags & LOOKUP_RCU) {
+                       nd->dpathbuf = kmalloc(PATH_MAX, GFP_ATOMIC);
+                       if (unlikely(!nd->dpathbuf))
+                               return -ECHILD;
+               } else {
+                       nd->dpathbuf = kmalloc(PATH_MAX, GFP_KERNEL);
+                       if (unlikely(!nd->dpathbuf))
+                               return -ENOMEM;
+               }
+       }
+       return 0;
+}

Note that a fixed-size path buffer means that if the path is very
long, e.g. because you followed long symlinks on the way down, this
can cause lookup failures.

This is already an issue with __d_path (even if the buffer was larger)
because it will not output a path longer than PATH_MAX. I imagine this
is a pretty strong argument for why we should refactor __d_path so that
we can *just* use the escape checking to avoid -ENAMETOOLONG.

Let me get it straight - the whole point of that buffer is to check
if __d_path() returns NULL?  So you allocate it so that you would have
place to copy the path components into... only to have them completely
ignored?

How is that different from path_is_under()?