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.
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"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…