CVS: cvs.openbsd.org: src

CVSROOT:	/cvs
Module name:	src
Changes by:	[email protected]	2026/07/14 06:13:54

Modified files:
	sys/kern       : Tag: OPENBSD_7_9 kern_sysctl.c sysv_msg.c 
	                 sysv_sem.c sysv_shm.c 

Log message:
Do not zeroize already zeroed buffer in sysctl_sysvipc(). The
KERN_SYSVIPC_SEM_INFO case was a part of the big semaphores diff,
KERN_SYSVIPC_SHM_INFO case to the next one.
from mvs@; ok deraadt

Replace semid_ds with semid_ds_kern for in-kernel sysv semaphore
implementation.
Note, the buffer used for userland dlivery in sysctl_sysvipc() was
filled with zeros during allocation, we don't need extra zeroing.
from mvs@; ok deraadt millert

Make concurrent sys_msgrcv() wait until we finish message delivery. We
left acquired message in the queue while we are sleeping in msg_copyout().
Concurrent sys_msgrcv() could acquire and delete this message.
Reported-by: [email protected]
from mvs@

Restore msgrcv(2) MSG_NOERROR/E2BIG error path. Silently truncate
message is not a good idea.
msgrcv(2) man page has E2BIG error description, no need for update.
from mvs@; ok millert

Drop sleeping malloc() handling in sysctl_sysvmsg(). msginfo.msgmni is
immutable, it can't be changed during sleep.
from mvs@; ok millert kirill

Declare immutable `msginfo' structure as const. Also, `msginfo' is local
to kern/sysv_msg.c, so remove declaration from sys/msg.h. This
declaration is not exposed to the userland. usr.bin/ipcs/ipcs.c has
"#define _KERNEL" before include SysV headers, but doesn't touch
`msginfo'.
from mvs@; ok deraadt

Make msg_copyout() to check the remaining space within userland buffer.
Otherwise, if the userland buffer size is smaller than the message size,
we write data beyond its end.
Use `xfer' for chunk size like msg_copyin() does.
from mvs@; ok cludwig

Calculate the msg_copyin() `xfer' as min(available space, ...) not
min(total space, ...). Otherwise we read outside of userland buffer.
Also, I like to use sizeof(variable) instead of sizeof(type).
from mvs@; ok cludwig

Drop unused 'struct proc' argument from msg_copyin() and msg_copyout().
from mvs@; ok claudio

Introduce reference counters for SysV semaphores to fix the context
switch use-after-free after tsleep in sys_semget().
sys___semctl() has no such problems, because we do complete reload and
re-check of semaphore stuff, however I like to replace all of them
with the only "semaptr != sema[ix]" check. The semaphore was changed, go
to the beginning of sys___semctl() and acquire it again.
Note, seminfo.semmni only grows, so even if `sema' array was
re-allocated, the sema[ix] is still valid.
from mvs@; "go for it" from deraadt

Replace semid_ds with semid_ds_kern for in-kernel sysv semaphore
implementation.
Note, the buffer used for userland dlivery in sysctl_sysvipc() was
filled with zeros during allocation, we don't need extra zeroing.
from mvs@; ok deraadt millert

Do sleeping malloc() and copyin() before checks within sys_semop().
Otherwise the semaphore id referenced by `semaptr' could be destroyed
or replaced during context switch.
from mvs@; ok cludwig

For IPC_STAT (and KERN_SYSVIPC_SHM_INFO) the three fields
__shm_atimensec/__shm_dtimensec/_shm_ctimensec fields leak kernel memory
contents because we never initialize them, they should clearly be zero
until such time as we add more precision.  The Tsinghua University group
suggested clearing these at export time, but the real problem is the
memory is being allocated without PR_ZERO.
from mvs@; ok kettenis mvs

Fix sys_shmat().
The shminfo.shmseg could be changed via sysctl during sleeping malloc().
It only grows, so we access memory outside of allocated chunk within the
following 'for' loop. This issue was exposed by syzkaller [1].
Also, p->p_vmspace points to the ps_vmspace common to the whole process,
so p->p_vmspace->vm_shm could be already set by concurrent sys_shmat()
thread. We need to check this case, otherwise the pointer to
concurrently allocated segment will be overwritten.
1. https://syzkaller.appspot.com/bug?extid=9669e87e543ae1f05884
from mvs@; ok deraadt

Limit the maximum value of shminfo.shmseg to prevent `size' overflow in
sys_shmat(). The default value of 128 is safe, but overflow could happen
on 32 bits machine while the value of shminfo.shmseg was raised too high.
from mvs@; Discussed with deraadt.

this is errata/7.9/005_sysv.patch.sig