e71e2ace57
Patch series "userfaultfd: do not untag user pointers", v5. If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. Also change the kselftest to use mmap so that it doesn't encounter this problem. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c This patch (of 2): Do not untag pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit |
||
|---|---|---|
| .. | ||
| acpi_object_usage.rst | ||
| amu.rst | ||
| arm-acpi.rst | ||
| booting.rst | ||
| cpu-feature-registers.rst | ||
| elf_hwcaps.rst | ||
| features.rst | ||
| hugetlbpage.rst | ||
| index.rst | ||
| kasan-offsets.sh | ||
| legacy_instructions.rst | ||
| memory-tagging-extension.rst | ||
| memory.rst | ||
| perf.rst | ||
| pointer-authentication.rst | ||
| silicon-errata.rst | ||
| sve.rst | ||
| tagged-address-abi.rst | ||
| tagged-pointers.rst | ||