diff for duplicates of <20170822102527.GA14671@leverpostej> diff --git a/a/1.txt b/N1/1.txt index 61f237c..552bc45 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,129 +4,3 @@ On Tue, Jul 11, 2017 at 03:16:28PM +0100, Mark Rutland wrote: > Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals > correctly, allowing unprivileged users to create an unkillable task which can > lock up the system. Please check whether your arch is affected. - -From a glance at v4.13-rc5, I believe this affects: - - alpha, cris, hexagon, ia64, m68k, metag, microblaze, mips, - mn10300, nios2, openrisc, parisc, sparc (32-bit), tile, - unicore32, xtensa - -... I'm not sure about: - - arc, s390, sparc (64-bit) - -... and I think that the following are ok: - - powerpc, sh, x86 - -Thanks, -Mark. - -> AFAICT, most arches don't correctly handle a fatal signal interrupting a -> uaccess fault. They attempt to bail out, returning to the faulting context -> without bothering to handle the fault, but forget to apply the uaccess fixup. -> Consequently, the uaccess gets replayed, and the same thing happens forver. -> -> When this occurs, the relevant task never returns to userspace, never handles -> the fatal signal, and is stuck in an unkillable (though interruptible and -> preemptible) state. The task can inhibit forward progress of the rest of the -> system, leading to RCU stalls and lockups. -> -> It's possible for an unprivileged user to trigger this deliberately using the -> userfaultfd syscall, as demonstrated by the test case at the end of this email -> (note: requires CONFIG_USERFAULTFD to be selected). I am not sure if this is -> the only way of triggering the issue. -> -> I stumbled upon this while fuzzing arm64 with Syzkaller. I've verified that -> both arm and arm64 have the issue, and by inspection is seems that the majority -> of other architectures are affected. -> -> It looks like this was fixed up for x86 in 2014 with commit: -> -> 26178ec11ef3c6c8 ("x86: mm: consolidate VM_FAULT_RETRY handling") -> -> ... but most other architectures never received a similar fixup. -> -> The duplication (and divergence) of this logic is unfortunate. It's largely -> copy-paste code that could be consolidated under mm/. -> -> Until we end up refactoring this, and so as to be sutiable for backporting, -> this series fixes arm and arm64 in-place. I've not touched other architectures -> as I don't have the relevant hardwre or arch knowledge. -> -> Thanks, -> Mark. -> -> ---- -> #include <errno.h> -> #include <linux/userfaultfd.h> -> #include <stdio.h> -> #include <sys/ioctl.h> -> #include <sys/mman.h> -> #include <sys/syscall.h> -> #include <sys/vfs.h> -> #include <unistd.h> -> -> int main(int argc, char *argv[]) -> { -> void *mem; -> long pagesz; -> int uffd, ret; -> struct uffdio_api api = { -> .api = UFFD_API -> }; -> struct uffdio_register reg; -> -> pagesz = sysconf(_SC_PAGESIZE); -> if (pagesz < 0) { -> return errno; -> } -> -> mem = mmap(NULL, pagesz, PROT_READ | PROT_WRITE, -> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); -> if (mem == MAP_FAILED) -> return errno; -> -> uffd = syscall(__NR_userfaultfd, 0); -> if (uffd < 0) -> return errno; -> -> ret = ioctl(uffd, UFFDIO_API, &api); -> if (ret < 0) -> return errno; -> -> reg = (struct uffdio_register) { -> .range = { -> .start = (unsigned long)mem, -> .len = pagesz -> }, -> .mode = UFFDIO_REGISTER_MODE_MISSING -> }; -> -> ret = ioctl(uffd, UFFDIO_REGISTER, ®); -> if (ret < 0) -> return errno; -> -> /* -> * Force an arbitrary uaccess to memory monitored by the userfaultfd. -> * This will block, but when a SIGKILL is sent, will consume all -> * available CPU time without being killed, and may inhibit forward -> * progress of the system. -> */ -> ret = fstatfs(0, (struct statfs *)mem); -> -> return 0; -> } -> ---- -> -> Mark Rutland (2): -> arm64: mm: abort uaccess retries upon fatal signal -> arm: mm: abort uaccess retries upon fatal signal -> -> arch/arm/mm/fault.c | 5 ++++- -> arch/arm64/mm/fault.c | 5 ++++- -> 2 files changed, 8 insertions(+), 2 deletions(-) -> -> -- -> 1.9.1 -> diff --git a/a/content_digest b/N1/content_digest index faaf093..2a76070 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -22,132 +22,6 @@ "> \n" "> Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals\n" "> correctly, allowing unprivileged users to create an unkillable task which can\n" - "> lock up the system. Please check whether your arch is affected.\n" - "\n" - "From a glance at v4.13-rc5, I believe this affects:\n" - "\n" - "\talpha, cris, hexagon, ia64, m68k, metag, microblaze, mips,\n" - "\tmn10300, nios2, openrisc, parisc, sparc (32-bit), tile,\n" - "\tunicore32, xtensa\n" - "\n" - "... I'm not sure about:\n" - "\n" - "\tarc, s390, sparc (64-bit)\n" - "\n" - "... and I think that the following are ok:\n" - "\n" - "\tpowerpc, sh, x86\n" - "\n" - "Thanks,\n" - "Mark.\n" - "\n" - "> AFAICT, most arches don't correctly handle a fatal signal interrupting a\n" - "> uaccess fault. They attempt to bail out, returning to the faulting context\n" - "> without bothering to handle the fault, but forget to apply the uaccess fixup.\n" - "> Consequently, the uaccess gets replayed, and the same thing happens forver.\n" - "> \n" - "> When this occurs, the relevant task never returns to userspace, never handles\n" - "> the fatal signal, and is stuck in an unkillable (though interruptible and\n" - "> preemptible) state. The task can inhibit forward progress of the rest of the\n" - "> system, leading to RCU stalls and lockups.\n" - "> \n" - "> It's possible for an unprivileged user to trigger this deliberately using the\n" - "> userfaultfd syscall, as demonstrated by the test case at the end of this email\n" - "> (note: requires CONFIG_USERFAULTFD to be selected). I am not sure if this is\n" - "> the only way of triggering the issue.\n" - "> \n" - "> I stumbled upon this while fuzzing arm64 with Syzkaller. I've verified that\n" - "> both arm and arm64 have the issue, and by inspection is seems that the majority\n" - "> of other architectures are affected.\n" - "> \n" - "> It looks like this was fixed up for x86 in 2014 with commit:\n" - "> \n" - "> 26178ec11ef3c6c8 (\"x86: mm: consolidate VM_FAULT_RETRY handling\")\n" - "> \n" - "> ... but most other architectures never received a similar fixup.\n" - "> \n" - "> The duplication (and divergence) of this logic is unfortunate. It's largely\n" - "> copy-paste code that could be consolidated under mm/.\n" - "> \n" - "> Until we end up refactoring this, and so as to be sutiable for backporting,\n" - "> this series fixes arm and arm64 in-place. I've not touched other architectures\n" - "> as I don't have the relevant hardwre or arch knowledge.\n" - "> \n" - "> Thanks,\n" - "> Mark.\n" - "> \n" - "> ----\n" - "> #include <errno.h>\n" - "> #include <linux/userfaultfd.h>\n" - "> #include <stdio.h>\n" - "> #include <sys/ioctl.h>\n" - "> #include <sys/mman.h>\n" - "> #include <sys/syscall.h>\n" - "> #include <sys/vfs.h>\n" - "> #include <unistd.h>\n" - "> \n" - "> int main(int argc, char *argv[])\n" - "> {\n" - "> \tvoid *mem;\n" - "> \tlong pagesz;\n" - "> \tint uffd, ret;\n" - "> \tstruct uffdio_api api = {\n" - "> \t\t.api = UFFD_API\n" - "> \t};\n" - "> \tstruct uffdio_register reg;\n" - "> \n" - "> \tpagesz = sysconf(_SC_PAGESIZE);\n" - "> \tif (pagesz < 0) {\n" - "> \t\treturn errno;\n" - "> \t}\n" - "> \n" - "> \tmem = mmap(NULL, pagesz, PROT_READ | PROT_WRITE,\n" - "> \t\t MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);\n" - "> \tif (mem == MAP_FAILED)\n" - "> \t\treturn errno;\n" - "> \n" - "> \tuffd = syscall(__NR_userfaultfd, 0);\n" - "> \tif (uffd < 0)\n" - "> \t\treturn errno;\n" - "> \n" - "> \tret = ioctl(uffd, UFFDIO_API, &api);\n" - "> \tif (ret < 0)\n" - "> \t\treturn errno;\n" - "> \n" - "> \treg = (struct uffdio_register) {\n" - "> \t\t.range = {\n" - "> \t\t\t.start = (unsigned long)mem,\n" - "> \t\t\t.len = pagesz\n" - "> \t\t},\n" - "> \t\t.mode = UFFDIO_REGISTER_MODE_MISSING\n" - "> \t};\n" - "> \n" - "> \tret = ioctl(uffd, UFFDIO_REGISTER, ®);\n" - "> \tif (ret < 0)\n" - "> \t\treturn errno;\n" - "> \n" - "> \t/*\n" - "> \t * Force an arbitrary uaccess to memory monitored by the userfaultfd.\n" - "> \t * This will block, but when a SIGKILL is sent, will consume all\n" - "> \t * available CPU time without being killed, and may inhibit forward\n" - "> \t * progress of the system.\n" - "> \t */\n" - "> \tret = fstatfs(0, (struct statfs *)mem);\n" - "> \n" - "> \treturn 0;\n" - "> }\n" - "> ----\n" - "> \n" - "> Mark Rutland (2):\n" - "> arm64: mm: abort uaccess retries upon fatal signal\n" - "> arm: mm: abort uaccess retries upon fatal signal\n" - "> \n" - "> arch/arm/mm/fault.c | 5 ++++-\n" - "> arch/arm64/mm/fault.c | 5 ++++-\n" - "> 2 files changed, 8 insertions(+), 2 deletions(-)\n" - "> \n" - "> -- \n" - "> 1.9.1\n" - > + > lock up the system. Please check whether your arch is affected. -9325716888ae9153bcea4619634d725800e2146730f17d34946dfbdfb1d3d16a +6b0f566df134d3898a076c5a50ca02ed81d1bbad5d38f5d75844497091c878a1
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox