linux-kernel - Re: Strange EFAULT on mips64el returned by syscall when another thread is forking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 25 Jan 2024 05:32:59 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Andreas Schwab <schwab@...e.de>, Ben Hutchings <ben@...adent.org.uk>
Cc: linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org, Jiaxun Yang
 <jiaxun.yang@...goat.com>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
  libc-alpha@...rceware.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Strange EFAULT on mips64el returned by syscall when another
 thread is forking

On Thu, 2024-01-25 at 00:13 +0800, Xi Ruoyao wrote:
> On Wed, 2024-01-24 at 20:49 +0800, Xi Ruoyao wrote:
> > On Wed, 2024-01-24 at 12:59 +0100, Andreas Schwab wrote:
> > > On Jan 24 2024, Xi Ruoyao wrote:
> > > 
> > > > Now I'm suspecting this might be a kernel bug.  Any pointer to further
> > > > triage?
> > > 
> > > Is this a regression?
> > 
> > Initially I guessed it was perhaps a Glibc regression related to the
> > newly introduced clone3 usage on MIPS, but it fails with Glibc-2.35 too.
> > 
> > Not sure if this is a kernel regression, I'll try different kernels in
> > several hours (once I can physically access the system).
> 
> Not happening with kernel 5.18.1.  I can do a bisection but it will take
> several days, I guess.

Hmm, not so time-consuming as I expected.

4bce37a68ff884e821a02a731897a8119e0c37b7 is the first bad commit
commit 4bce37a68ff884e821a02a731897a8119e0c37b7
Author: Ben Hutchings <ben@...adent.org.uk>
Date:   Thu Jun 22 18:47:40 2023 +0200

    mips/mm: Convert to using lock_mm_and_find_vma()

Re-posting the broken test case for Ben (I also added a waitpid call to
prevent PID exhaustion):

#include <stdlib.h>
#include <errno.h>
#include <pthread.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>

void *
test_thread (void *)
{
  char buf[16] = {};
  int fd = open("/dev/zero", O_RDONLY);
  while (1)
    {
      ssize_t ret = read (fd, buf, 7);
      if (ret == -1 && errno == EFAULT)
        abort ();
    }
}

void *
fork_thread (void *)
{
  while (1)
    {
      pid_t p = fork ();
      if (!p)
        _exit (0);
      waitpid (p, NULL, 0);
    }
}

int
main (void)
{
  pthread_t test_th;
  pthread_t fork_th;

  pthread_create (&test_th, NULL, test_thread, NULL);
  pthread_create (&fork_th, NULL, fork_thread, NULL);
  pthread_join (test_th, NULL);
  pthread_join (fork_th, NULL);
}

and the context where this issue was detected:

https://sourceware.org/glibc/wiki/Testing/Tests/stdlib/tst-arc4random-thread

and the "interesting" aspects:

1. If I change the third parameter of "read" to any value >= 8, it no
longer fails.  But it fails with any integer in [1, 8).
2. It fails no matter if I initialize buf.
3. It does not fail on arm64 (the only other port using
lock_mm_and_find_vma I have access to).

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University