Fixes bug in sys_symlink
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 6 Mar 2013 21:09:46 +0000 (13:09 -0800)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 6 Mar 2013 21:09:46 +0000 (13:09 -0800)
Clearly we should have been using the trusted / memduped strings,
instead of the user strings.  What's more interesting is that this used
to work, but recently page faults.

For those curious, the actual page fault happened a few bytes into
new_path, during link_path_walk().  Checking out 'showmappings' (look at
the page table), the page is mapped, but it is only mapped read-only.
Since the kernel honors read only flags in PTEs (due to the CR0 flag),
the kernel page faulted on an illegal write access on a read-only page.

Now as to why this didn't happen 2.5 years ago, either we've done
something since then to honor read-only mappings of binaries, the
compiler decided to make it read-only, or qemu/kvm wasn't previously
honoring the CR0 flag.

kern/src/syscall.c

index 9beb176..44194bf 100644 (file)
@@ -1343,7 +1343,7 @@ intreg_t sys_symlink(struct proc *p, char *old_path, size_t old_l,
                user_memdup_free(p, t_oldpath);
                return -1;
        }
-       ret = do_symlink(new_path, old_path, S_IRWXU | S_IRWXG | S_IRWXO);
+       ret = do_symlink(t_newpath, t_oldpath, S_IRWXU | S_IRWXG | S_IRWXO);
        user_memdup_free(p, t_oldpath);
        user_memdup_free(p, t_newpath);
        return ret;