From: Kai Kang <kai.kang@...>

According to oe-core commit

652fdf8719 sstate: Allow validation of sstate singatures against list of keys

pkgconfig-native is not deployed in sysroot by default any more. Inherit
pkgconfig.bbclass to make it work for ceph.

Signed-off-by: Kai Kang <kai.kang@...>
---
recipes-extended/ceph/ceph_15.2.12.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/ceph/ceph_15.2.12.bb b/recipes-extended/ceph/ceph_15.2.12.bb
index 6636d7a..693b525 100644
--- a/recipes-extended/ceph/ceph_15.2.12.bb
+++ b/recipes-extended/ceph/ceph_15.2.12.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://COPYING-LGPL2.1;md5=fbc093901857fcd118f065f900982c24
file://COPYING-GPL2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://COPYING;md5=4eb012c221c5fd4b760029a2981a6754 \
"
-inherit cmake python3native python3-dir systemd
+inherit cmake pkgconfig python3native python3-dir systemd
# Disable python pybind support for ceph temporary, when corss compiling pybind,
# pybind mix cmake and python setup environment, would case a lot of errors.

--
2.17.1

Hi,

I am running the dunfell branch and I notice
that ip6tables is not getting installed:

# podman run hello-world
Trying to pull docker.io/library/hello-world...
Getting image source signatures
Copying blob 93288797bd35 done
Copying config 18e5af7904 done
Writing manifest to image destination
Storing signatures
[ 41.667476] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 41.674442] cni-podman0: port 1(veth5ab23089) entered blocking state
[ 41.680912] cni-podman0: port 1(veth5ab23089) entered disabled state
[ 41.687634] device veth5ab23089 entered promiscuous mode
[ 41.693058] audit: type=1700 audit(1634272456.424:3): dev=veth5ab23089 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 41.694135] cni-podman0: port 1(veth5ab23089) entered blocking state
[ 41.711492] cni-podman0: port 1(veth5ab23089) entered forwarding state
[ 41.856399] audit: type=1325 audit(1634272456.604:4): table=nat family=2 entries=0 op=xt_register pid=481 comm="modprobe"
[ 41.867521] audit: type=1325 audit(1634272456.612:5): table=nat family=2 entries=5 op=xt_replace pid=482 comm="iptables"
[ 41.883462] audit: type=1325 audit(1634272456.632:6): table=nat family=2 entries=7 op=xt_replace pid=485 comm="iptables"
[ 41.899451] audit: type=1325 audit(1634272456.648:7): table=nat family=2 entries=8 op=xt_replace pid=488 comm="iptables"
[ 41.910483] audit: type=1325 audit(1634272456.656:8): table=nat family=2 entries=9 op=xt_replace pid=490 comm="iptables"
ERRO[0004] Error adding network: could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH
ERRO[0004] Error while adding pod to CNI network "podman": could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH
[ 41.973531] cni-podman0: port 1(veth5ab23089) entered disabled state
[ 41.981035] device veth5ab23089 left promiscuous mode
[ 41.986213] cni-podman0: port 1(veth5ab23089) entered disabled state
[ 41.986238] audit: type=1700 audit(1634272456.736:9): dev=veth5ab23089 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
Error: error configuring network namespace for container 173dbac37c7b288e2a932ef9e6fa2c05c50a30305f46b1ddbd6208b8d77e76de: could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH

What could be the reason for ip6tables executable not getting installed?

I have also cherry-picked the commit below to dunfell, but it did not help:
https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=35fce40e86c6cd475d24136c699ae1f2821dea85

Thanks,

Fabio Estevam
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...

Hi Bruce,

Could you please cherry-pick the following commit into dunfell?

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-core?id=94501882dcf6eec411d68696e59953653c787eab

It fixes the following run-time error when launching podman:

Error: error configuring CNI network plugin: exec: "nsenter": executable file not found in $PATH

Thanks,

Fabio Estevam
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...

On Wed, Oct 13, 2021 at 10:18 AM Marc Wiz <mwyocto@...> wrote:

I recently discovered a couple of issues with building crun.

The first issue is when using a proxy to download source. crun depends on libocispec which is a git sub-module. The proxy environment variables are apparently not passed or recognized by the git sub-module code . The fix is to add the proxy configuration into the git configuration.

The real issue IMHO is that crun depends on libocispec which depends on yajl. Yajl is not downloaded until the compile task for crun is executed. This breaks offline builds.

So I am wondering what the best way is to address this? It seems to me that the Makefiles for libocispec and yajl would need to be modified and the recipe for crun would need to be modified to fetch the dependencies.

All of those dependencies are already specified in the recipe, and in
any integration/build testing that I've done, they are all picked up
properly.

libocispec is directly specified in the SRC_URI and placed where crun
will look for it, so that happens in the fetch task.

yajl is specified in DEPENDS, so it will be in place in the recipe
sysroot before compilation starts. You get a build error without
yajl, so it is properly in place for the builds that I'm doing.

Bruce

Thanks,
Marc

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

I recently discovered a couple of issues with building crun.

The first issue is when using a proxy to download source.   crun depends on libocispec which is a git sub-module.  The proxy environment variables are apparently not passed or recognized by the git sub-module code .  The fix is to add the proxy configuration into the git configuration.

The real issue IMHO is that crun depends on libocispec which depends on yajl.  Yajl is not downloaded until the compile task for crun is executed.  This breaks offline builds.

So I am wondering what the best way is to address this?  It seems to me that the Makefiles for libocispec and yajl would need to be modified and the recipe for crun would need to be modified to fetch the dependencies.

Thanks,
Marc

On Tue, Oct 12, 2021 at 2:02 PM Bruce Ashfield <bruce.ashfield@...> wrote:

We can't bump hardknott ahead of master, but as it turns out, I
already have pending k*s updates for master, so I can cherry pick them
to the stable branches after I'm finished testing.

Ooops. My mistake, I read that version number as 1.21, not 1.20.

This is fine for hardknott and won't interfere with my master /
release branch bumps.

Bruce

Bruce

On Tue, Oct 12, 2021 at 1:52 PM Diego Sueiro <diego.sueiro@...> wrote:

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
recipes-containers/k3s/k3s_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-containers/k3s/k3s_git.bb b/recipes-containers/k3s/k3s_git.bb
index 2811fb8..f51d9d4 100644
--- a/recipes-containers/k3s/k3s_git.bb
+++ b/recipes-containers/k3s/k3s_git.bb
@@ -13,9 +13,9 @@ SRC_URI = "git://github.com/rancher/k3s.git;branch=release-1.20;name=k3s \
file://0001-Finding-host-local-in-usr-libexec.patch;patchdir=src/import \
"
SRC_URI[k3s.md5sum] = "363d3a08dc0b72ba6e6577964f6e94a5"
-SRCREV_k3s = "bc400f5396a3dd05584c5f45768a5ea6c43971d1"
+SRCREV_k3s = "9cb5fb5716bdfb13e755206aff5688961f5bafb3"

-PV = "v1.20.4+k3s1"
+PV = "v1.20.11+k3s2"

CNI_NETWORKING_FILES ?= "${WORKDIR}/cni-containerd-net.conf"

--
2.17.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

We can't bump hardknott ahead of master, but as it turns out, I
already have pending k*s updates for master, so I can cherry pick them
to the stable branches after I'm finished testing.

Bruce

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
recipes-containers/k3s/k3s_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-containers/k3s/k3s_git.bb b/recipes-containers/k3s/k3s_git.bb
index 2811fb8..f51d9d4 100644
--- a/recipes-containers/k3s/k3s_git.bb
+++ b/recipes-containers/k3s/k3s_git.bb
@@ -13,9 +13,9 @@ SRC_URI = "git://github.com/rancher/k3s.git;branch=release-1.20;name=k3s \
file://0001-Finding-host-local-in-usr-libexec.patch;patchdir=src/import \
"
SRC_URI[k3s.md5sum] = "363d3a08dc0b72ba6e6577964f6e94a5"
-SRCREV_k3s = "bc400f5396a3dd05584c5f45768a5ea6c43971d1"
+SRCREV_k3s = "9cb5fb5716bdfb13e755206aff5688961f5bafb3"

-PV = "v1.20.4+k3s1"
+PV = "v1.20.11+k3s2"

CNI_NETWORKING_FILES ?= "${WORKDIR}/cni-containerd-net.conf"

--
2.17.1

merged.

Bruce

In message: [meta-virtualization] [PATCH] xen: add missing pkgconfig inherit
on 12/10/2021 Ross Burton wrote:

New oe-core pulls in less default dependencies[1], so add an explicit
inherit of pkgconfig as it is needed to configure Xen.

[1] https://lists.openembedded.org/g/openembedded-core/message/156185

Signed-off-by: Ross Burton <ross.burton@...>
---
recipes-extended/xen/xen.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index c0a087e..d3c7a7d 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -2,7 +2,7 @@ HOMEPAGE =3D "http://xen.org"
LICENSE =3D "GPLv2"
SECTION =3D "console/tools"
=20
-inherit autotools-brokensep
+inherit autotools-brokensep pkgconfig
=20
require xen-arch.inc
=20
--=20
2.25.1

On 10/1/21 10:50 AM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]
In message: [meta-virtualization][hardknott][PATCH] openvswitch: Security fix for CVE-2021-36980
on 29/09/2021 Xu, Yanfei wrote:

Open vSwitch (aka openvswitch) 2.11.0 through 2.15.0 has
a use-after-free in decode_NXAST_RAW_ENCAP (called from
ofpact_decode and ofpacts_decode) during the decoding of
a RAW_ENCAP action.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36980

Patches from:
format-patch from ovs v2.15.1

Signed-off-by: Yanfei Xu <yanfei.xu@...>
---
...use-after-free-while-decoding-RAW_EN.patch | 101 ++++++++++++++++++
.../openvswitch/openvswitch_git.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644 recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch

diff --git a/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
new file mode 100644
index 00000000..c88c097d
--- /dev/null
+++ b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
@@ -0,0 +1,101 @@
+From 802a31a7070cea910b95d7e926c9da30a1f9e54f Mon Sep 17 00:00:00 2001
+From: Ilya Maximets <i.maximets@...>
+Date: Tue, 16 Feb 2021 23:27:30 +0100
+Subject: [PATCH] ofp-actions: Fix use-after-free while decoding RAW_ENCAP.
+
+While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
+ofpbuf if there is no enough space left. However, function
+'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
+structure leading to write-after-free and incorrect decoding.
+
+ ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
+ 0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
+ WRITE of size 2 at 0x60600000011a thread T0
+ #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
+ #1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
+ #2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
+ #3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
+ #4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
+ #5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
+ #6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
+ #7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
+ #8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
+ #9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
+ #10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
+ #11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
+ #12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
+ #13 0x5391ae in main utilities/ovs-ofctl.c:179:9
+ #14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
+ #15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
+
+Fix that by getting a new pointer before using.
+
+Credit to OSS-Fuzz.
+
+Fuzzer regression test will fail only with AddressSanitizer enabled.
+
+Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
+Fixes: f839892a206a ("OF support and translation of generic encap and decap")
+Acked-by: William Tu <u9012063@...>
+Signed-off-by: Ilya Maximets <i.maximets@...>
+
+Upstream-Status: Backport
+CVE: CVE-2021-36980
+Signed-off-by: Yanfei Xu <yanfei.xu@...>
+---
+ lib/ofp-actions.c | 2 ++
+ tests/automake.mk | 3 ++-
+ tests/fuzz-regression-list.at | 1 +
+ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 | 0
+ 4 files changed, 5 insertions(+), 1 deletion(-)
+ create mode 100644 tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+
+diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
+index e2e829772..0342a228b 100644
+--- a/lib/ofp-actions.c
++++ b/lib/ofp-actions.c
+@@ -4431,6 +4431,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ {
+ struct ofpact_encap *encap;
+ const struct ofp_ed_prop_header *ofp_prop;
++ const size_t encap_ofs = out->size;
+ size_t props_len;
+ uint16_t n_props = 0;
+ int err;
+@@ -4458,6 +4459,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ }
+ n_props++;
+ }
++ encap = ofpbuf_at_assert(out, encap_ofs, sizeof *encap);
+ encap->n_props = n_props;
+ out->header = &encap->ofpact;
+ ofpact_finish_ENCAP(out, &encap);
+diff --git a/tests/automake.mk b/tests/automake.mk
+index 677b99a6b..fc80e027d 100644
+--- a/tests/automake.mk
++++ b/tests/automake.mk
+@@ -134,7 +134,8 @@ FUZZ_REGRESSION_TESTS = \
+ tests/fuzz-regression/ofp_print_fuzzer-5722747668791296 \
+ tests/fuzz-regression/ofp_print_fuzzer-6285128790704128 \
+ tests/fuzz-regression/ofp_print_fuzzer-6470117922701312 \
+- tests/fuzz-regression/ofp_print_fuzzer-6502620041576448
++ tests/fuzz-regression/ofp_print_fuzzer-6502620041576448 \
++ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+ $(srcdir)/tests/fuzz-regression-list.at: tests/automake.mk
+ $(AM_V_GEN)for name in $(FUZZ_REGRESSION_TESTS); do \
+ basename=`echo $$name | sed 's,^.*/,,'`; \
+diff --git a/tests/fuzz-regression-list.at b/tests/fuzz-regression-list.at
+index e3173fb88..2347c690e 100644
+--- a/tests/fuzz-regression-list.at
++++ b/tests/fuzz-regression-list.at
+@@ -21,3 +21,4 @@ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-5722747668791296])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6285128790704128])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6470117922701312])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6502620041576448])
++TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6540965472632832])
+diff --git a/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 b/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+new file mode 100644
+index 000000000..e69de29bb
+--
+2.27.0
+
diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb
index 16ec4c72..56f1297c 100644
--- a/recipes-networking/openvswitch/openvswitch_git.bb
+++ b/recipes-networking/openvswitch/openvswitch_git.bb
@@ -30,6 +30,7 @@ SRC_URI += "git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.15
file://0001-ovs-use-run-instead-of-var-run-for-in-systemd-units.patch \
file://0001-openvswitch-fix-do_configure-with-DPDK-19.11-error.patch \
file://0001-openvswitch-fix-netdev-dpdk-compile-error.patch \
+ file://0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch \

Sorry for this late rely due to a long vocation.

You are carrying local patches to your ovs recipe that don't match meta-virt.
As such, this didn't directly apply. I fixed it up and merged it.
> But you should consider carrying those patches in a bbappend, so that
upstream sends like this have proper context, and I can be more sure
of the testing that is done on submissions.

Thanks for remainding.

I also took this as an opportunity to bump OVS in master, since I wanted
to be sure that we have the same CVE addressed there.

I notice the ovs has been updated to 2.15.1, thanks a lot.

Cheers,
Yanfei

Bruce

"

LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab"
--
2.27.0

FYI: Christopher is having a look at these updates.

I just wanted to let everyone know that they haven't been missed.

Bruce

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Adding kernel-modules did the trick, the docker daemon issued iptables command now works and supports --to-destination for dnat.

Thank-you Bruce for taking the time to explain, I've learned a ton in the process!


On 01/10/2021, 13:50, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Fri, Oct 1, 2021 at 4:35 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Yes, you're spot on!
>
> Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"
>

In the K3S recipe, we actually have finer grained RRECOMMENDS than the
docker recipes (due to the way k3s was developed and integrated).

In K3S, I'm currently tracking:

RRECOMMENDS:${PN} = "\
kernel-module-xt-addrtype \
kernel-module-xt-nat \
kernel-module-xt-multiport \
kernel-module-xt-conntrack \
kernel-module-xt-comment \
kernel-module-xt-mark \
kernel-module-xt-connmark \
kernel-module-vxlan \
kernel-module-xt-masquerade \
"

So you could try that list, or do what I normally recommend .. use the
meta package "kernel-modules" and get everything that was built. Since
if you are using a linux-yocto variant, you'll already be getting
fragments to build the right modules as part of the kernel build.

I do have a new set of tested planned for the fall that do barebones
testing to ensure that we've fully listed the rdepends/rrcommends for
many of the recipes in meta-virt.

But for now, I'd recommend that larger package, or you can do what I
did for k3s. Build a package-feed enabled image, start docker, look at
the error messages, install the required module, and then repeat to
get the minimum list (if a kernel module wasn't being built at all,
you may need to do some rebuilding in the middle).

Bruce


> But running the config script still shows the output below:
>
> root@generic-arm64:/usr/share/docker# ./check-config.sh
> info: reading kernel config from /proc/config.gz ...
> Generally Necessary:
> - cgroup hierarchy: properly mounted [/sys/fs/cgroup]
> - CONFIG_NAMESPACES: enabled
> - CONFIG_NET_NS: enabled
> - CONFIG_PID_NS: enabled
> - CONFIG_IPC_NS: enabled
> - CONFIG_UTS_NS: enabled
> - CONFIG_CGROUPS: enabled
> - CONFIG_CGROUP_CPUACCT: enabled
> - CONFIG_CGROUP_DEVICE: enabled
> - CONFIG_CGROUP_FREEZER: missing
> - CONFIG_CGROUP_SCHED: enabled
> - CONFIG_CPUSETS: enabled
> - CONFIG_MEMCG: enabled
> - CONFIG_KEYS: enabled
> - CONFIG_VETH: enabled
> - CONFIG_BRIDGE: enabled (as module)
> - CONFIG_BRIDGE_NETFILTER: missing
> - CONFIG_NF_NAT_IPV4: missing
> - CONFIG_IP_NF_FILTER: enabled (as module)
> - CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_IPVS: missing
> - CONFIG_IP_NF_NAT: enabled (as module)
> - CONFIG_NF_NAT: enabled (as module)
> - CONFIG_NF_NAT_NEEDED: missing
> - CONFIG_POSIX_MQUEUE: enabled
>
> On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
> >
> > Thanks for the reply Bruce __ Let me know if these details help?
> >
> > root@generic-arm64:~# uname -r
> > 5.10.46-yocto-standard
> >
> > Only setting these two kernel configs at the moment:
> > CONFIG_ENA_ETHERNET=y
> > CONFIG_BLK_DEV_NVME=y
>
> It'll be the iptables and cgroups options that are causing issues.
>
> The standard layers and kernel are extensively tested with meta-virt,
> so there really shouldn't be something missing.
>
> You can also install the docker-contrib package to your image, and run
> the check-config.sh script to see if it reports any issues.
>
> Bruce
>
> >
> > And these are the layers, running harknott...
> > drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> > drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> > drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> > drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> > drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
> >
> >
> > On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
> >
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> > <stephibb=amazon.co.uk@...> wrote:
> > >
> > > Hello all!
> > >
> > > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> > >
> > > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> > >
> > > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> > >
> > > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> > >
> > > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> > >
> > > Any ideas for workarounds would be very much appreciated!
> >
> > It's your kernel configuration, coupled with the iptables modules
> > available .. but most often, it is a missing kernel module.
> >
> > So without knowing exactly what kernel and hardware you are running,
> > it is hard to say more.
> >
> > Bruce
> >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> >
> > Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
> >
> > Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

On Fri, Oct 1, 2021 at 4:35 AM Hibbert, Stephen <stephibb@...> wrote:

Yes, you're spot on!

Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"

In the K3S recipe, we actually have finer grained RRECOMMENDS than the
docker recipes (due to the way k3s was developed and integrated).

In K3S, I'm currently tracking:

RRECOMMENDS:${PN} = "\
kernel-module-xt-addrtype \
kernel-module-xt-nat \
kernel-module-xt-multiport \
kernel-module-xt-conntrack \
kernel-module-xt-comment \
kernel-module-xt-mark \
kernel-module-xt-connmark \
kernel-module-vxlan \
kernel-module-xt-masquerade \
"

So you could try that list, or do what I normally recommend .. use the
meta package "kernel-modules" and get everything that was built. Since
if you are using a linux-yocto variant, you'll already be getting
fragments to build the right modules as part of the kernel build.

I do have a new set of tested planned for the fall that do barebones
testing to ensure that we've fully listed the rdepends/rrcommends for
many of the recipes in meta-virt.

But for now, I'd recommend that larger package, or you can do what I
did for k3s. Build a package-feed enabled image, start docker, look at
the error messages, install the required module, and then repeat to
get the minimum list (if a kernel module wasn't being built at all,
you may need to do some rebuilding in the middle).

Bruce

But running the config script still shows the output below:

root@generic-arm64:/usr/share/docker# ./check-config.sh
info: reading kernel config from /proc/config.gz ...
Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: missing
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: missing
- CONFIG_NF_NAT_IPV4: missing
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: missing
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing
- CONFIG_POSIX_MQUEUE: enabled

On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Thanks for the reply Bruce __ Let me know if these details help?
>
> root@generic-arm64:~# uname -r
> 5.10.46-yocto-standard
>
> Only setting these two kernel configs at the moment:
> CONFIG_ENA_ETHERNET=y
> CONFIG_BLK_DEV_NVME=y

It'll be the iptables and cgroups options that are causing issues.

The standard layers and kernel are extensively tested with meta-virt,
so there really shouldn't be something missing.

You can also install the docker-contrib package to your image, and run
the check-config.sh script to see if it reports any issues.

Bruce

>
> And these are the layers, running harknott...
> drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
>
>
> On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> <stephibb=amazon.co.uk@...> wrote:
> >
> > Hello all!
> >
> > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> >
> > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> >
> > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> >
> > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> >
> > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> >
> > Any ideas for workarounds would be very much appreciated!
>
> It's your kernel configuration, coupled with the iptables modules
> available .. but most often, it is a missing kernel module.
>
> So without knowing exactly what kernel and hardware you are running,
> it is hard to say more.
>
> Bruce
>
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Yes, you're spot on!

Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"

But running the config script still shows the output below:

root@generic-arm64:/usr/share/docker# ./check-config.sh
info: reading kernel config from /proc/config.gz ...
Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: missing
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: missing
- CONFIG_NF_NAT_IPV4: missing
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: missing
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing
- CONFIG_POSIX_MQUEUE: enabled

On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Thanks for the reply Bruce __ Let me know if these details help?
>
> root@generic-arm64:~# uname -r
> 5.10.46-yocto-standard
>
> Only setting these two kernel configs at the moment:
> CONFIG_ENA_ETHERNET=y
> CONFIG_BLK_DEV_NVME=y

It'll be the iptables and cgroups options that are causing issues.

The standard layers and kernel are extensively tested with meta-virt,
so there really shouldn't be something missing.

You can also install the docker-contrib package to your image, and run
the check-config.sh script to see if it reports any issues.

Bruce

>
> And these are the layers, running harknott...
> drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
>
>
> On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> <stephibb=amazon.co.uk@...> wrote:
> >
> > Hello all!
> >
> > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> >
> > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> >
> > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> >
> > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> >
> > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> >
> > Any ideas for workarounds would be very much appreciated!
>
> It's your kernel configuration, coupled with the iptables modules
> available .. but most often, it is a missing kernel module.
>
> So without knowing exactly what kernel and hardware you are running,
> it is hard to say more.
>
> Bruce
>
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

In message: [meta-virtualization][hardknott][PATCH] openvswitch: Security fix for CVE-2021-36980
on 29/09/2021 Xu, Yanfei wrote:

Open vSwitch (aka openvswitch) 2.11.0 through 2.15.0 has
a use-after-free in decode_NXAST_RAW_ENCAP (called from
ofpact_decode and ofpacts_decode) during the decoding of
a RAW_ENCAP action.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36980

Patches from:
format-patch from ovs v2.15.1

Signed-off-by: Yanfei Xu <yanfei.xu@...>
---
...use-after-free-while-decoding-RAW_EN.patch | 101 ++++++++++++++++++
.../openvswitch/openvswitch_git.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644 recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch

diff --git a/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
new file mode 100644
index 00000000..c88c097d
--- /dev/null
+++ b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
@@ -0,0 +1,101 @@
+From 802a31a7070cea910b95d7e926c9da30a1f9e54f Mon Sep 17 00:00:00 2001
+From: Ilya Maximets <i.maximets@...>
+Date: Tue, 16 Feb 2021 23:27:30 +0100
+Subject: [PATCH] ofp-actions: Fix use-after-free while decoding RAW_ENCAP.
+
+While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
+ofpbuf if there is no enough space left. However, function
+'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
+structure leading to write-after-free and incorrect decoding.
+
+ ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
+ 0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
+ WRITE of size 2 at 0x60600000011a thread T0
+ #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
+ #1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
+ #2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
+ #3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
+ #4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
+ #5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
+ #6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
+ #7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
+ #8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
+ #9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
+ #10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
+ #11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
+ #12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
+ #13 0x5391ae in main utilities/ovs-ofctl.c:179:9
+ #14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
+ #15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
+
+Fix that by getting a new pointer before using.
+
+Credit to OSS-Fuzz.
+
+Fuzzer regression test will fail only with AddressSanitizer enabled.
+
+Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
+Fixes: f839892a206a ("OF support and translation of generic encap and decap")
+Acked-by: William Tu <u9012063@...>
+Signed-off-by: Ilya Maximets <i.maximets@...>
+
+Upstream-Status: Backport
+CVE: CVE-2021-36980
+Signed-off-by: Yanfei Xu <yanfei.xu@...>
+---
+ lib/ofp-actions.c | 2 ++
+ tests/automake.mk | 3 ++-
+ tests/fuzz-regression-list.at | 1 +
+ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 | 0
+ 4 files changed, 5 insertions(+), 1 deletion(-)
+ create mode 100644 tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+
+diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
+index e2e829772..0342a228b 100644
+--- a/lib/ofp-actions.c
++++ b/lib/ofp-actions.c
+@@ -4431,6 +4431,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ {
+ struct ofpact_encap *encap;
+ const struct ofp_ed_prop_header *ofp_prop;
++ const size_t encap_ofs = out->size;
+ size_t props_len;
+ uint16_t n_props = 0;
+ int err;
+@@ -4458,6 +4459,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ }
+ n_props++;
+ }
++ encap = ofpbuf_at_assert(out, encap_ofs, sizeof *encap);
+ encap->n_props = n_props;
+ out->header = &encap->ofpact;
+ ofpact_finish_ENCAP(out, &encap);
+diff --git a/tests/automake.mk b/tests/automake.mk
+index 677b99a6b..fc80e027d 100644
+--- a/tests/automake.mk
++++ b/tests/automake.mk
+@@ -134,7 +134,8 @@ FUZZ_REGRESSION_TESTS = \
+ tests/fuzz-regression/ofp_print_fuzzer-5722747668791296 \
+ tests/fuzz-regression/ofp_print_fuzzer-6285128790704128 \
+ tests/fuzz-regression/ofp_print_fuzzer-6470117922701312 \
+- tests/fuzz-regression/ofp_print_fuzzer-6502620041576448
++ tests/fuzz-regression/ofp_print_fuzzer-6502620041576448 \
++ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+ $(srcdir)/tests/fuzz-regression-list.at: tests/automake.mk
+ $(AM_V_GEN)for name in $(FUZZ_REGRESSION_TESTS); do \
+ basename=`echo $$name | sed 's,^.*/,,'`; \
+diff --git a/tests/fuzz-regression-list.at b/tests/fuzz-regression-list.at
+index e3173fb88..2347c690e 100644
+--- a/tests/fuzz-regression-list.at
++++ b/tests/fuzz-regression-list.at
+@@ -21,3 +21,4 @@ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-5722747668791296])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6285128790704128])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6470117922701312])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6502620041576448])
++TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6540965472632832])
+diff --git a/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 b/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+new file mode 100644
+index 000000000..e69de29bb
+--
+2.27.0
+
diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb
index 16ec4c72..56f1297c 100644
--- a/recipes-networking/openvswitch/openvswitch_git.bb
+++ b/recipes-networking/openvswitch/openvswitch_git.bb
@@ -30,6 +30,7 @@ SRC_URI += "git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.15
file://0001-ovs-use-run-instead-of-var-run-for-in-systemd-units.patch \
file://0001-openvswitch-fix-do_configure-with-DPDK-19.11-error.patch \
file://0001-openvswitch-fix-netdev-dpdk-compile-error.patch \
+ file://0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch \

You are carrying local patches to your ovs recipe that don't match meta-virt.

As such, this didn't directly apply. I fixed it up and merged it.

But you should consider carrying those patches in a bbappend, so that
upstream sends like this have proper context, and I can be more sure
of the testing that is done on submissions.

I also took this as an opportunity to bump OVS in master, since I wanted
to be sure that we have the same CVE addressed there.

Bruce

"

LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab"
--
2.27.0