In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix GSO userspace truncation underflow
OVSACTIONATTRTRUNC currently stores a delta from the original skb length in OVSCB(skb)->cutlen. When a later userspace action segments a GSO skb, queuegsopackets() reuses that delta for each smaller segment. A segment can then reach queueuserspacepacket() with cutlen greater than skb->len, underflowing the length passed to skbzerocopy().
Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: cap upcall PID array size and pre-size vport replies
The vport netlink reply helpers allocate a fixed-size skb with nlmsgnew(NLMSGDEFAULTSIZE, ...) but serialize the full upcall PID array via ovsvportgetupcallportids(). Since ovsvportsetupcallportids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAPNETADMIN user can install a PID array large enough to overflow the reply buffer, causing nlaput() to fail with -EMSGSIZE and hitting BUGON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENLUNSADMINPERM.
kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovsvportcmdset+0x34c/0x400 Call Trace: <TASK> genlfamilyrcvmsgdoit (net/netlink/genetlink.c:1116) genlrcvmsg (net/netlink/genetlink.c:1194) netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) syssendto (net/socket.c:2206) x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK> Kernel panic - not syncing: Fatal exception
Reject attempts to set more PIDs than nrcpuids in ovsvportsetupcallportids(), and pre-compute the worst-case reply size in ovsvportcmdmsgsize() based on that bound, similar to the existing ovsdpcmdmsgsize(). nrcpuids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovsdpcmdfillinfo() serialises at most nrcpuids PIDs), so the two sides stay consistent.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: defer tunnel netdevput to RCU release
ovsnetdevtunneldestroy() may run after NETDEVUNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.
Do not release vport->dev in ovsnetdevtunneldestroy(). Instead, let vportnetdevfree() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.