Christoph Hellwig <hch@xxxxxx> writes:
> Both exec and exit want to ensure that the uaccess routines actually do
> access user pointers. Use the newly added force_uaccess_begin helper
> instead of an open coded set_fs for that to prepare for kernel builds
> where set_fs() does not exist.
Acked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Have you played with a tree with all of your patches
and placing force_uaccess_begin in init/main.c:start_kernel?
Somewhere deep in the arch code we seem to have it all backwards
and kernel threads are all set_fs(KERNEL_DS). So just putting
a force_uaccess_begin somewhere very early should be enough
to switch things around.
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
> fs/exec.c | 7 ++++++-
> kernel/exit.c | 2 +-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index e6e8a9a7032784..769af470b69124 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1380,7 +1380,12 @@ int begin_new_exec(struct linux_binprm * bprm)
> if (retval)
> goto out_unlock;
>
> - set_fs(USER_DS);
> + /*
> + * Ensure that the uaccess routines can actually operate on userspace
> + * pointers:
> + */
> + force_uaccess_begin();
> +
> me->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD |
> PF_NOFREEZE | PF_NO_SETAFFINITY);
> flush_thread();
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 727150f2810338..17d486a20f0dc6 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -731,7 +731,7 @@ void __noreturn do_exit(long code)
> * mm_release()->clear_child_tid() from writing to a user-controlled
> * kernel address.
> */
> - set_fs(USER_DS);
> + force_uaccess_begin();
>
> if (unlikely(in_atomic())) {
> pr_info("note: %s[%d] exited with preempt_count %d\n",
