FKIE_CVE-2025-68785
Vulnerability from fkie_nvd - Published: 2026-01-13 16:15 - Updated: 2026-04-15 00:35
Severity ?
Summary
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:
OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))
The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the
nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost
OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()
inside nsh_key_put_from_nlattr(). But nothing checks if the attribute
in the middle is OK. We don't even check that this attribute is the
OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()
calls - first time directly while calling validate_push_nsh() and the
second time as part of the nla_for_each_nested() 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 nsh_hdr_from_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>
dump_stack_lvl+0x51/0x70
print_address_description.constprop.0+0x2c/0x390
kasan_report+0xdd/0x110
kasan_check_range+0x35/0x1b0
__asan_memcpy+0x20/0x60
nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]
push_nsh+0x82/0x120 [openvswitch]
do_execute_actions+0x1405/0x2840 [openvswitch]
ovs_execute_actions+0xd5/0x3b0 [openvswitch]
ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]
genl_family_rcv_msg_doit+0x1d6/0x2b0
genl_family_rcv_msg+0x336/0x580
genl_rcv_msg+0x9f/0x130
netlink_rcv_skb+0x11f/0x370
genl_rcv+0x24/0x40
netlink_unicast+0x73e/0xaa0
netlink_sendmsg+0x744/0xbf0
__sys_sendto+0x3d6/0x450
do_syscall_64+0x79/0x2c0
entry_SYSCALL_64_after_hwframe+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 OVS_KEY_ATTR_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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix middle attribute validation in push_nsh() action\n\nThe push_nsh() action structure looks like this:\n\n OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))\n\nThe outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK\u0027ed by the\nnla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost\nOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK\u0027ed by the nla_for_each_nested()\ninside nsh_key_put_from_nlattr(). But nothing checks if the attribute\nin the middle is OK. We don\u0027t even check that this attribute is the\nOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()\ncalls - first time directly while calling validate_push_nsh() and the\nsecond time as part of the nla_for_each_nested() macro, which isn\u0027t\nsafe, potentially causing invalid memory access if the size of this\nattribute is incorrect. The failure may not be noticed during\nvalidation due to larger netlink buffer, but cause trouble later during\naction execution where the buffer is allocated exactly to the size:\n\n BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n Read of size 184 at addr ffff88816459a634 by task a.out/22624\n\n CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x2c/0x390\n kasan_report+0xdd/0x110\n kasan_check_range+0x35/0x1b0\n __asan_memcpy+0x20/0x60\n nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n push_nsh+0x82/0x120 [openvswitch]\n do_execute_actions+0x1405/0x2840 [openvswitch]\n ovs_execute_actions+0xd5/0x3b0 [openvswitch]\n ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]\n genl_family_rcv_msg_doit+0x1d6/0x2b0\n genl_family_rcv_msg+0x336/0x580\n genl_rcv_msg+0x9f/0x130\n netlink_rcv_skb+0x11f/0x370\n genl_rcv+0x24/0x40\n netlink_unicast+0x73e/0xaa0\n netlink_sendmsg+0x744/0xbf0\n __sys_sendto+0x3d6/0x450\n do_syscall_64+0x79/0x2c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u003c/TASK\u003e\n\nLet\u0027s add some checks that the attribute is properly sized and it\u0027s\nthe only one attribute inside the action. Technically, there is no\nreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we\u0027re\npushing an NSH header already, it just creates extra nesting, but\nthat\u0027s how uAPI works today. So, keeping as it is."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnet: openvswitch: corrige la validaci\u00f3n del atributo intermedio en la acci\u00f3n push_nsh()\n\nLa estructura de la acci\u00f3n push_nsh() se ve as\u00ed:\n\n OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))\n\nEl atributo m\u00e1s externo OVS_ACTION_ATTR_PUSH_NSH es validado por nla_for_each_nested() dentro de __ovs_nla_copy_actions(). Los atributos m\u00e1s internos OVS_NSH_KEY_ATTR_BASE/MD1/MD2 son validados por nla_for_each_nested() dentro de nsh_key_put_from_nlattr(). Pero nada verifica si el atributo del medio es v\u00e1lido. Ni siquiera verificamos que este atributo sea OVS_KEY_ATTR_NSH. Simplemente hacemos un doble unwrap con un par de llamadas a nla_data() - la primera vez directamente al llamar a validate_push_nsh() y la segunda vez como parte de la macro nla_for_each_nested(), lo cual no es seguro, pudiendo causar acceso a memoria inv\u00e1lido si el tama\u00f1o de este atributo es incorrecto. El fallo podr\u00eda no ser notado durante la validaci\u00f3n debido a un b\u00fafer netlink m\u00e1s grande, pero causar problemas m\u00e1s tarde durante la ejecuci\u00f3n de la acci\u00f3n donde el b\u00fafer se asigna exactamente al tama\u00f1o:\n\n BUG: KASAN: slab-out-of-bounds en nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n Lectura de tama\u00f1o 184 en la direcci\u00f3n ffff88816459a634 por la tarea a.out/22624\n\n CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)\n Traza de Llamadas:\n \n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x2c/0x390\n kasan_report+0xdd/0x110\n kasan_check_range+0x35/0x1b0\n __asan_memcpy+0x20/0x60\n nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n push_nsh+0x82/0x120 [openvswitch]\n do_execute_actions+0x1405/0x2840 [openvswitch]\n ovs_execute_actions+0xd5/0x3b0 [openvswitch]\n ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]\n genl_family_rcv_msg_doit+0x1d6/0x2b0\n genl_family_rcv_msg+0x336/0x580\n genl_rcv_msg+0x9f/0x130\n netlink_rcv_skb+0x11f/0x370\n genl_rcv+0x24/0x40\n netlink_unicast+0x73e/0xaa0\n netlink_sendmsg+0x744/0xbf0\n __sys_sendto+0x3d6/0x450\n do_syscall_64+0x79/0x2c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \n\nA\u00f1adamos algunas verificaciones de que el atributo tiene el tama\u00f1o adecuado y es el \u00fanico atributo dentro de la acci\u00f3n. T\u00e9cnicamente, no hay una raz\u00f3n real para que OVS_KEY_ATTR_NSH est\u00e9 all\u00ed, ya que sabemos que ya estamos pusheando un encabezado NSH, solo crea anidamiento adicional, pero as\u00ed es como funciona la uAPI hoy. As\u00ed que, lo mantenemos como est\u00e1."
}
],
"id": "CVE-2025-68785",
"lastModified": "2026-04-15T00:35:42.020",
"metrics": {},
"published": "2026-01-13T16:15:58.227",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/10ffc558246f2c75619aedda0921906095e46702"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1b569db9c2f28b599e40050524aae5f7332bc294"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2ecfc4433acdb149eafd7fb22d7fd4adf90b25e9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3bc2efff20a38b2c7ca18317649715df0dd62ced"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5ace7ef87f059d68b5f50837ef3e8a1a4870c36e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c999153bfb2d1d9b295b7010d920f2a7c6d7595f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d0c135b8bbbcf92836068fd395bebeb7ae6c7bef"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…