Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 8 Feb 2024 21:23:05 +0100
From: Ilya Maximets <>
 ovs-discuss <>
Cc:, Aaron Conole <>,
 Flavio Leitner <>
Subject: [ADVISORY] CVE-2023-5366: Open vSwitch: OpenFlow match on Neighbor
 Discovery Target may be ignored


In multiple versions of Open vSwitch, if OpenFlow rules on a switch
contain a match on a Target Address (nd_target) of Neighbor Discovery
IPv6 packets (Neighbor Solicitation or Neighbor Advertisement) without
also matching on ICMPv6 Code (icmp_code or icmpv6_code) field being
zero, the match on the Target Address can be ignored and the specified
actions may be executed for a packet with a different Target Address.

This constitutes vulnerability if such OpenFlow rules are used in order
to provide Neighbor Discovery anti-spoofing protection.  For example,
the following set of rules may allow packets with any nd_target, even
though it should only allow packets with the 2001::1 Target:

  priority=10 icmp6,icmpv6_type=136,nd_target=2001::1 actions=<allow>
  priority=0  icmp6 actions=drop

The issue is caused by the difference between the OpenFlow specification
that only lists ICMPV6 TYPE=135 or ICMPV6 TYPE=136 as a prerequisite for
the IPV6_ND_TARGET and datapath implementations that treat ICMPV6_CODE=0
as a requirement for a packet to have the Target Address option.  This
leads to creation of an overly broad datapath flow that matches packets
regardless of the Target Address value.

Triggering the issue depends on the order in which packets are seen
by the switch.

Open vSwitch versions 2.1 and newer are affected.

The Common Vulnerabilities and Exposures project ( has
assigned CVE-2023-5366 identifier to this issue.


For any affected version of Open vSwitch, adding an icmpv6_code=0 match
to an OpenFlow rule will mitigate the issue.  For example:

 priority=10 icmp6,icmpv6_type=136,icmpv6_code=0,nd_target=2001::1 \
 priority=0  icmp6 actions=drop

'icmpv6_code' corresponds to OXM_OF_ICMPV6_CODE staring with OF1.2
or NXM_OF_ICMPV6_CODE Nicira Extension before that.


Patches to fix this vulnerability in Open vSwitch 2.17 and newer has been
applied to the appropriate branches:

 * 3.2.x:
 * 3.1.x:
 * 3.0.x:
 * 2.17.x:

The original patch is located at:

Note for those performing selective patch backports:

  The following change is a prerequisite for the fix and must also be
  applied for the fix to work correctly:


We recommend that users of Open vSwitch apply the respective patches,
or upgrade to a known patched version of Open vSwitch.  These include:

 * 3.2.2
 * 3.1.4
 * 3.0.6
 * 2.17.9

However, while patches are enough to fix the issue, checking both the
ICMPv6 Code and Type is *the correct way* to validate Neighbor Discovery
packets according to RFC 4861.  With this in mind, we recommend that
users follow the mitigation strategy even with the patches applied,
i.e. add an extra match criteria on 'icmpv6_code' field.


The Open vSwitch team wishes to thank the reporters:

 * Alex Katz <>
 * Slawomir Kaplonski <>
Download attachment "OpenPGP_0xB9F7EC77C829BF96.asc" of type "application/pgp-keys" (6329 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.