CVE-2025-68785

In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix middle attribute validation in push_nsh() action

The push_nsh() action structure looks like this:

OVSACTIONATTRPUSHNSH(OVSKEYATTRNSH(OVSNSHKEYATTR_BASE,...))

The outermost OVSACTIONATTRPUSHNSH attribute is OK'ed by the nlaforeach_nested() inside _ovsnlacopyactions(). The innermost OVSNSHKEYATTRBASE/MD1/MD2 are OK'ed by the nlaforeachnested() inside nshkeyputfromnlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVSKEYATTRNSH. We just do a double unwrap with a pair of nladata() calls - first time directly while calling validatepushnsh() and the second time as part of the nlaforeachnested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size:

BUG: KASAN: slab-out-of-bounds in nshhdrfrom_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624

CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x2c/0x390 kasanreport+0xdd/0x110 kasancheck_range+0x35/0x1b0 __asanmemcpy+0x20/0x60 nshhdrfromnlattr+0x1dd/0x6a0 [openvswitch] pushnsh+0x82/0x120 [openvswitch] doexecuteactions+0x1405/0x2840 [openvswitch] ovsexecuteactions+0xd5/0x3b0 [openvswitch] ovspacketcmdexecute+0x949/0xdb0 [openvswitch] genlfamilyrcvmsgdoit+0x1d6/0x2b0 genlfamilyrcvmsg+0x336/0x580 genlrcvmsg+0x9f/0x130 netlinkrcvskb+0x11f/0x370 genlrcv+0x24/0x40 netlinkunicast+0x73e/0xaa0 netlinksendmsg+0x744/0xbf0 _syssendto+0x3d6/0x450 dosyscall64+0x79/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVSKEYATTR_NSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is.