stale value can be returned and this causes a diagnostic panic in
namei.
In relookup(), clear *vpp before calling VOP_LOOKUP, as is done in
lookup_once(), as an additional precautionary measure.
(in theory both of these fixes are not required together)
Should fix PR 47040.
3383. [security] A certain combination of records in the RBT could
cause named to hang while populating the additional
section of a response. [RT #31090]
adapted from OpenBSD with various improvements, no support for Expert3D has
been added
this is still suboptimal since we have to sync the engine all the time but
it's an improvement over software-only operation
by calling NDAT(&nd, dirvp) after NDINIT().
Right now the implementation is vile and unspeakable to avoid changing
the kernel ABI; this way we can get openat() and friends into 6.1. I
will rectify the mess and bump the kernel once things are working.
the system and eventually cause a watchdog timer to reset. Instead use
softints for "small" number of packets and use a workqueue thread for large
numbers. This allows receive processing to be handling at normal priorities
and won't starve out other parts of the system.
ranges to the default dma tag. This has the side effect of making most initial
bus_dmamem_allocs trying to get memory from the first 256MB which is coherent
on this platform.
data, fixing up only the RST to the initial SYN. This makes off-path attacks
more difficult. For the reference, see "Reflection Scan: an Off-Path Attack
on TCP" by Jan Wrobel.
caused by the sequence of passing two fd's with two sendmsg()'s,
then doing a read() and a recvmsg(). The read() calls dom_dispose()
which discards both messages in the mbuf, and sets the fp's in the
array to NULL. Linux dequeues only one message per read() so the
second recvmsg() gets the fd from the second message. This fix
just avoids the NULL pointer de-reference, making the second
recvmsg() to fail. It is dubious to pass fd's with stream sockets
and expect mixing read() and recvmsg() to work. Plus processing
one control message per read() changes the current semantics and
should be examined before applied. In addition there is a race between
dom_externalize() and dom_dispose(): what happens in a multi-threaded
network stack when one thread disposes where the other externalizes
the same array?
NB: Pullup to 6.
