Hi,

I have seen a crash in pcb_lookup -> SipHash_End -> explicit_bzero
-> memset.  Retguard found that the stack was corrupt with 0 bytes.
Message is SipHash_End+0x16d int $3.  Instead of clearing the
SIPHASH_CTX on the stack, rep stosb in memset destroyed the stack
frame.  The DF bit in the rflags is set, so the stack has been
cleared in the wrong direction.

Only kcopy and memmove use std to set DF bit.  kcopy has the special
property that it can fault.  Then DF is set in the trap frame.
kpageflttrap() changes the return address to copy_fault via
pcb_onfault.  When alltraps_kern returns, it restores the rflags
with DF set and jumps into copy_fault.  From there we do a function
return into the kernel.  From now on DF is set, but kernel memset
expects that it is cleared.

A possible place where kcopy() may fail is sys_kbind().  uvm_map_extract()
creates an uvm object, but when kcopy() faults, it may have been
destroyed by another thread.

Fix is easy, after copy fault, also reset the DF bit.  Crash happend
on OpenBSD 7.4 amd64, i386 code looks similar.

ok?

bluhm

Index: arch/amd64/amd64/copy.S
===================================================================
RCS file: /data/mirror/openbsd/cvs/src/sys/arch/amd64/amd64/copy.S,v
diff -u -p -r1.19 copy.S
--- arch/amd64/amd64/copy.S	28 Jul 2023 06:18:35 -0000	1.19
+++ arch/amd64/amd64/copy.S	5 Jun 2024 13:51:37 -0000
@@ -189,6 +189,7 @@ ENTRY(_copyin)
 
 NENTRY(copy_fault)
 DECLARE_ONFAULT(copy_fault)
+	cld
 	SMAP_CLAC
 	movq	CPUVAR(CURPCB),%rdx
 	popq	PCB_ONFAULT(%rdx)
Index: arch/i386/i386/locore.s
===================================================================
RCS file: /data/mirror/openbsd/cvs/src/sys/arch/i386/i386/locore.s,v
diff -u -p -r1.204 locore.s
--- arch/i386/i386/locore.s	12 Dec 2023 07:37:20 -0000	1.204
+++ arch/i386/i386/locore.s	5 Jun 2024 13:51:25 -0000
@@ -555,6 +555,7 @@ ENTRY(_copyin)
 	ret
 
 ENTRY(copy_fault)
+	cld
 	SMAP_CLAC
 	GET_CURPCB(%edx)
 	popl	PCB_ONFAULT(%edx)