In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Don't use testbit() in lockless RCU readers in hash types
Sashiko pointed out that there are a few lockless RCU readers using testbit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use testbitacquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases
- protected by region lock - in a set destroy phase - in a new/temporary set creation phase
In the Linux kernel, the following vulnerability has been resolved:
ovpn: respect peer refcount in CMDNEWPEER error path
ovpnnlpeernewdoit()'s error path calls ovpnpeerrelease() directly rather than ovpnpeerput(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP.
For UDP, the ovpnsocket union uses the .ovpn arm and never points back at a peer; UDP encaprecv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpnpeeradd() publishes it.
For TCP, ovpnsocketnew() sets ovpnsock->peer and ovpntcpsocketattach() publishes ovpnsock via rcuassignskuserdata(). From that moment until ovpnsocketrelease() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpntcprcv() path, can reach the peer through skuserdata -> ovpnsock->peer and bump its refcount via ovpnpeerhold().
ovpntcpsocketwaitfinish() (called inside ovpnsocketrelease()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpnnlpeermodify() or ovpnpeeradd() returns an error while such a caller is in flight - notably an ovpntcprecvmsg() blocked in skbrecvdatagram() on peer->tcp.userqueue - the direct ovpnpeerrelease() destroys the peer while the caller still holds the reference, and the eventual ovpnpeerput() from that caller operates on freed memory.
Replace the direct destructor call with ovpnpeerput() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpnpeerreleasekref() runs the same destructor.
With this conversion ovpnpeerrelease() has no callers outside peer.c - ovpnpeerreleasekref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: fix unaligned memory access in timestamp adjustment
Use getunalignedbe32() and putunalignedbe32() to safely read and write the timestamp fields. This prevents performance degradation due to unaligned memory access or even a crash on strict alignment architectures.
This follows the implementation of timestamp parsing in the networking stack at tcpparseoptions() and synproxyparseoptions().
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix use-after-free in ip6finishoutput2()
ip6finishoutput2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnelxmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnelxmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnelxmit() returns LWTUNNELXMITCONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system.
Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnelxmit() returns LWTUNNELXMITCONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.