check the signal number to be in the allowed range. An invalid
signal number could crash the kernel by overflowing the sigset_t
array.
More checks would be good, and SIGEV_THREAD shouldn't be dropped
silently, but this fixes at least the local DOS vulnerability.
Split a segment if its size is larger than dm_maxsegsz.
iommu_dvmamap_load_raw:
Don't coalesce segments if total size is larger than dm_maxsegsz.
This should fix port-sparc64/35299.
-an invalid signal number passed to mq_notify(2) could crash the kernel
on delivery -- add a boundary check
-mq_receive(2) from an empty queue crashed the kernel by NULL dereference
in timeout calculation -- handle the NULL case
-likewise for mq_send(2) to a full queue
-a user could set mq_maxmsg (the maximal number of messages in a queue)
to a huge value on mq_open(O_CREAT) and later use up all kernel
memory by mq_send(2) -- add a sysctl'able limit which defaults
to 16*mq_def_maxmsg
(mq_notify(2) should get some more checks, and SIGEV_* values other
than SIGEV_SIGNAL should be handled somehow, but this doesn't look
security critical)
do drain' in many places, whereas fo_drain() was called in order to force
blocking read()/write() etc calls to return to userspace so that a close()
call from a different thread can complete.
In the sockets code comment out the broken code in the inner function,
it was being called from compat code.
BaiYang per PR lib/42434
the sad truth is that this doesn't help much because SIGEV_THREAD just
doesn't work (at least on -current, likely on -5, perhaps it worked
woth scheduler activations)
list of sources. This, in a rather curious twist of linker magic,
broke anything using rump file systems when librumpvfs was compiled
with LIBDPLIBS pointing to librump.
Thanks to the several people who reported the problem, and especially
Arnaud Ysmal for noticing the paramount symptom that components
compiled in src/lib did not work while ones compiled in sys/rump/librump
did work.
They were incorrect since 1997 on amiga and atari, and since 2002
on other ports, but fortunately they don't look so fatal.
Anyway, these values will be moved into <m68k/pmap_motorola.h> soon
since they are quite pmap implementation dependent.
patch OSIOC{G,S}IFFLAGS is supposed to work, but unfortunately getifaddrs
seems to be the next problem getting the 4.99.x i386 ifconfig working on an
amd64 current machine.
to ${LD} via:
${LDADD.${PROG}}
${LDFLAGS.${PROG}}
${LDSTATIC.${PROG}}
${LDADD.${LIB}}
${LDFLAGS.${LIB}}
OTOH you can't pass parameters to ${CC}, because in suffix rules make(1) only
knows the name of ${.IMPSRC} and ${.TARGET}; it's users' responsivility to
define ${CC} parameters to all the sources of a given ${PROG} / ${LIB}.
Should address bin/42381.
(Bug in this commit log was pointed out by mrg@.)
njoly