uvm_km_pgremove: pmap_update before freeing pages
Update the commentary in uvm_km_free to reflect this reality while here
Reviewd by skrll@
PR kern/60376
t_mbstowcs: Mark UTF-8 test cases xfail.
mbrtowc fails to reject invalid (legacy 5/6-byte) UTF-8.
Need to split this test up into:
1. correctly decoding the valid inputs
2. correctly rejecting the invalid inputs
Also don't stop at the first failing test in t_mbrtowc; keep going to
test everything, for better diagnostics at the end in the test
report.
As with t_mbrtowc, this should be split into multiple parts, TBD.
PR lib/60369: mbrtowc, mbrlen have wrong return value for some
invalid byte sequences: Invalid sequence
mm(4): Only grant kva exposure if user opens /dev/kmem.
Don't apply the same to /dev/null, /dev/zero, or anything else.
PR kern/60374: opening /dev/null exposes kva
compat32: Fix accidental use of error branch in recvmsg(2).
Avoids use-after-free / double-free.
PR kern/60373: compat32: kernel use-after-free in recvmsg
Pull up following revision(s) (requested by nia in ticket #2004):
lib/libnvmm/libnvmm.c: revision 1.21 (patch)
libnvmm(3): Check return value of malloc.
adapted from a patch by Aaron LI at DragonflyBSD, commit id
7c543ef0a3b08473f10dcc066e531c459fbc3879
Pull up following revision(s) (requested by kbowling in ticket #2022):
sys/uvm/uvm_km.c: revision 1.167
uvm_km_pgremove_intrsafe: drain TLB shootdown before freeing pages
Call pmap_update(pmap_kernel()) between pmap_kremove and the page
free so the shootdown completes first.
Reviewed by skrll@
Pull up following revision(s) (requested by kbowling in ticket #1292):
sys/uvm/uvm_km.c: revision 1.167
uvm_km_pgremove_intrsafe: drain TLB shootdown before freeing pages
Call pmap_update(pmap_kernel()) between pmap_kremove and the page
free so the shootdown completes first.
Reviewed by skrll@
Pull up following revision(s) (requested by kbowling in ticket #345):
sys/uvm/uvm_km.c: revision 1.167
uvm_km_pgremove_intrsafe: drain TLB shootdown before freeing pages
Call pmap_update(pmap_kernel()) between pmap_kremove and the page
free so the shootdown completes first.
Reviewed by skrll@
lua(4): Fix and test some issues.
- Require read permission for LUAINFO.
- Require write permission for all others:
. LUACREATE
. LUADESTROY
. LUALOAD
. LUAREQUIRE
- Don't panic in LUAINFO if there's zero states.
- Add missing sys/stdbool.h in sys/lua.h.
This is not a real test suite for lua.kmod -- it doesn't verify the
module does anything useful; it just verifies that _if_ you go out of
your way to load the experimental kernel module, it doesn't enable
unprivileged users to wreak havoc with /dev/lua.
PR misc/60375: lua.kmod enables local privilege escalation
Pull up following revision(s) (requested by riastradh in ticket #2021):
distrib/sets/lists/tests/mi: revision 1.1404
libexec/ld.elf_so/headers.c: revision 1.76
tests/libexec/ld.elf_so/t_dladdr.c: revision 1.1
tests/libexec/ld.elf_so/t_dladdr.c: revision 1.2
tests/libexec/ld.elf_so/Makefile: revision 1.31
distrib/sets/lists/debug/mi: revision 1.493
dl_addr(3): Add some automatic tests.
XXX Should also test the libc stubs, maybe move this into
tests/lib/libc/dlfcn and test both static and (for MKPIC=yes)
dynamic, but this'll do for now.
PR lib/59567: dladdr(3) doesn't work properly especially when main
executable is loaded at high memory address
dladdr(3): Fix determination of object address intervals.
[26 lines not shown]
MAKEDEV: Set default perms on /dev/lua to 0600.
Otherwise unprivileged users can submit Lua code into the kernel, if
lua.kmod is loaded (which doesn't happen by default, not even
autoloaded on demand).
PR misc/60375: lua.kmod enables local privilege escalation
Pull up following revision(s) (requested by riastradh in ticket #1291):
distrib/sets/lists/tests/mi: revision 1.1404
libexec/ld.elf_so/headers.c: revision 1.76
tests/libexec/ld.elf_so/t_dladdr.c: revision 1.1
tests/libexec/ld.elf_so/t_dladdr.c: revision 1.2
tests/libexec/ld.elf_so/Makefile: revision 1.31
distrib/sets/lists/debug/mi: revision 1.493
dl_addr(3): Add some automatic tests.
XXX Should also test the libc stubs, maybe move this into
tests/lib/libc/dlfcn and test both static and (for MKPIC=yes)
dynamic, but this'll do for now.
PR lib/59567: dladdr(3) doesn't work properly especially when main
executable is loaded at high memory address
dladdr(3): Fix determination of object address intervals.
[26 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #2020):
usr.bin/mail/mail.1: revision 1.70
mail(1): document "list" command
Provide courtesy xrefs to "headers" and "z".
PR bin/59671
Pull up following revision(s) (requested by riastradh in ticket #1290):
usr.bin/mail/mail.1: revision 1.70
mail(1): document "list" command
Provide courtesy xrefs to "headers" and "z".
PR bin/59671
Pull up following revision(s) (requested by riastradh in ticket #342):
usr.bin/mail/mail.1: revision 1.70
mail(1): document "list" command
Provide courtesy xrefs to "headers" and "z".
PR bin/59671
Pull up following revision(s) (requested by riastradh in ticket #2019):
tests/net/net/t_unix.c: revision 1.26
tests/net/net/t_unix.c: revision 1.27
tests/net/net/t_unix.c: revision 1.28
sys/kern/uipc_usrreq.c: revision 1.208
t_unix: Sort includes.
No functional change intended.
Preparation for:
PR kern/59220: accept(2): null pointer deref
t_unix: Make existing tests more reliable by exiting in child.
Returning into atf in the child is not helpful.
Preparation for adding a test for:
PR kern/59220: accept(2): null pointer deref
[17 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1289):
tests/net/net/t_unix.c: revision 1.26
tests/net/net/t_unix.c: revision 1.27
tests/net/net/t_unix.c: revision 1.28
sys/kern/uipc_usrreq.c: revision 1.208
t_unix: Sort includes.
No functional change intended.
Preparation for:
PR kern/59220: accept(2): null pointer deref
t_unix: Make existing tests more reliable by exiting in child.
Returning into atf in the child is not helpful.
Preparation for adding a test for:
PR kern/59220: accept(2): null pointer deref
[17 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #2018):
external/cddl/osnet/dist/lib/libuutil/common/uu_list.c: revision 1.2
lib/libc/gen/arc4random.c: revision 1.51
external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c: revision 1.5
lib/libbsdmalloc/malloc.c: revision 1.13
external/cddl/osnet/dist/lib/libuutil/common/uu_avl.c: revision 1.2
external/cddl/osnet/dist/lib/libuutil/common/libuutil_impl.h: revision 1.2
lib/libc/stdlib/malloc.c: revision 1.61
(all via patch)
arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
[24 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1288):
external/cddl/osnet/dist/lib/libuutil/common/uu_list.c: revision 1.2
lib/libc/gen/arc4random.c: revision 1.51
external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c: revision 1.5
lib/libbsdmalloc/malloc.c: revision 1.13
external/cddl/osnet/dist/lib/libuutil/common/uu_avl.c: revision 1.2
external/cddl/osnet/dist/lib/libuutil/common/libuutil_impl.h: revision 1.2
lib/libc/stdlib/malloc.c: revision 1.61
arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
libbsdmalloc: Use mutex_init, not mutex_unlock, in child post-fork.
[23 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #341):
external/cddl/osnet/dist/lib/libuutil/common/uu_list.c: revision 1.2
lib/libc/gen/arc4random.c: revision 1.51
external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c: revision 1.5
lib/libbsdmalloc/malloc.c: revision 1.13
external/cddl/osnet/dist/lib/libuutil/common/uu_avl.c: revision 1.2
external/cddl/osnet/dist/lib/libuutil/common/libuutil_impl.h: revision 1.2
lib/libc/stdlib/malloc.c: revision 1.61
arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
libbsdmalloc: Use mutex_init, not mutex_unlock, in child post-fork.
[23 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1287):
lib/libbsdmalloc/malloc.c: revision 1.12
ensure the lock is released for all returns in malloc
Pull up following revision(s) (requested by riastradh in ticket #340):
lib/libbsdmalloc/malloc.c: revision 1.12
ensure the lock is released for all returns in malloc
