diff options
Diffstat (limited to 'poky/meta/recipes-devtools/qemu')
8 files changed, 470 insertions, 47 deletions
diff --git a/poky/meta/recipes-devtools/qemu/qemu.inc b/poky/meta/recipes-devtools/qemu/qemu.inc index 4c9be91cb0..c8e1d28654 100644 --- a/poky/meta/recipes-devtools/qemu/qemu.inc +++ b/poky/meta/recipes-devtools/qemu/qemu.inc @@ -36,6 +36,11 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ file://qemu-guest-agent.init \ file://qemu-guest-agent.udev \ file://ppc.patch \ + file://CVE-2023-0330.patch \ + file://CVE-2023-3301.patch \ + file://CVE-2023-3255.patch \ + file://CVE-2023-2861.patch \ + file://CVE-2023-3354.patch \ " UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar" diff --git a/poky/meta/recipes-devtools/qemu/qemu/0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch b/poky/meta/recipes-devtools/qemu/qemu/0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch index 5ef1184e3c..36c537eee1 100644 --- a/poky/meta/recipes-devtools/qemu/qemu/0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch +++ b/poky/meta/recipes-devtools/qemu/qemu/0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch @@ -8,7 +8,7 @@ The event filename is an absolute path. Convert it to a relative path when writing '#line' directives, to preserve reproducibility of the generated output when different base paths are used. -Upstream-Status: Pending +Upstream-Status: Accepted [https://gitlab.com/qemu-project/qemu/-/commit/9d672e290475001fcecdcc9dc79ad088ff89d17f] --- scripts/tracetool/backend/ftrace.py | 4 +++- diff --git a/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch new file mode 100644 index 0000000000..f609ea29b4 --- /dev/null +++ b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch @@ -0,0 +1,75 @@ +From b987718bbb1d0eabf95499b976212dd5f0120d75 Mon Sep 17 00:00:00 2001 +From: Thomas Huth <thuth@redhat.com> +Date: Mon, 22 May 2023 11:10:11 +0200 +Subject: [PATCH] hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI + controller (CVE-2023-0330) + +We cannot use the generic reentrancy guard in the LSI code, so +we have to manually prevent endless reentrancy here. The problematic +lsi_execute_script() function has already a way to detect whether +too many instructions have been executed - we just have to slightly +change the logic here that it also takes into account if the function +has been called too often in a reentrant way. + +The code in fuzz-lsi53c895a-test.c has been taken from an earlier +patch by Mauro Matteo Cascella. + +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1563 +Message-Id: <20230522091011.1082574-1-thuth@redhat.com> +Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> +Reviewed-by: Alexander Bulekov <alxndr@bu.edu> +Signed-off-by: Thomas Huth <thuth@redhat.com> + +Upstream-Status: Backport [https://gitlab.com/qemu-project/qemu/-/commit/b987718bbb1d0eabf95499b976212dd5f0120d75] +CVE: CVE-2023-0330 + +Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com> +--- + hw/scsi/lsi53c895a.c | 23 +++++++++++++++------ + tests/qtest/fuzz-lsi53c895a-test.c | 33 ++++++++++++++++++++++++++++++ + 2 files changed, 50 insertions(+), 6 deletions(-) + +diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c +index 048436352b7a..f7d45b0b20fb 100644 +--- a/hw/scsi/lsi53c895a.c ++++ b/hw/scsi/lsi53c895a.c +@@ -1134,15 +1134,24 @@ static void lsi_execute_script(LSIState *s) + uint32_t addr, addr_high; + int opcode; + int insn_processed = 0; ++ static int reentrancy_level; ++ ++ reentrancy_level++; + + s->istat1 |= LSI_ISTAT1_SRUN; + again: +- if (++insn_processed > LSI_MAX_INSN) { +- /* Some windows drivers make the device spin waiting for a memory +- location to change. If we have been executed a lot of code then +- assume this is the case and force an unexpected device disconnect. +- This is apparently sufficient to beat the drivers into submission. +- */ ++ /* ++ * Some windows drivers make the device spin waiting for a memory location ++ * to change. If we have executed more than LSI_MAX_INSN instructions then ++ * assume this is the case and force an unexpected device disconnect. This ++ * is apparently sufficient to beat the drivers into submission. ++ * ++ * Another issue (CVE-2023-0330) can occur if the script is programmed to ++ * trigger itself again and again. Avoid this problem by stopping after ++ * being called multiple times in a reentrant way (8 is an arbitrary value ++ * which should be enough for all valid use cases). ++ */ ++ if (++insn_processed > LSI_MAX_INSN || reentrancy_level > 8) { + if (!(s->sien0 & LSI_SIST0_UDC)) { + qemu_log_mask(LOG_GUEST_ERROR, + "lsi_scsi: inf. loop with UDC masked"); +@@ -1596,6 +1605,8 @@ static void lsi_execute_script(LSIState *s) + } + } + trace_lsi_execute_script_stop(); ++ ++ reentrancy_level--; + } + + static uint8_t lsi_reg_readb(LSIState *s, int offset) diff --git a/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch new file mode 100644 index 0000000000..34be8afe16 --- /dev/null +++ b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch @@ -0,0 +1,171 @@ +From f6b0de53fb87ddefed348a39284c8e2f28dc4eda Mon Sep 17 00:00:00 2001 +From: Christian Schoenebeck <qemu_oss@crudebyte.com> +Date: Wed, 2 Aug 2023 13:02:55 +0000 +Subject: [PATCH] 9pfs: prevent opening special files (CVE-2023-2861) + +The 9p protocol does not specifically define how server shall behave when +client tries to open a special file, however from security POV it does +make sense for 9p server to prohibit opening any special file on host side +in general. A sane Linux 9p client for instance would never attempt to +open a special file on host side, it would always handle those exclusively +on its guest side. A malicious client however could potentially escape +from the exported 9p tree by creating and opening a device file on host +side. + +With QEMU this could only be exploited in the following unsafe setups: + + - Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough' + security model. + +or + + - Using 9p 'proxy' fs driver (which is running its helper daemon as + root). + +These setups were already discouraged for safety reasons before, +however for obvious reasons we are now tightening behaviour on this. + +Fixes: CVE-2023-2861 +Reported-by: Yanwu Shen <ywsPlz@gmail.com> +Reported-by: Jietao Xiao <shawtao1125@gmail.com> +Reported-by: Jinku Li <jkli@xidian.edu.cn> +Reported-by: Wenbo Shen <shenwenbo@zju.edu.cn> +Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> +Reviewed-by: Greg Kurz <groug@kaod.org> +Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> +Message-Id: <E1q6w7r-0000Q0-NM@lizzy.crudebyte.com> + +CVE: CVE-2023-2861 + +Upstream-Status: Backport [https://github.com/qemu/qemu/commit/10fad73a2bf1c76c8aa9d6322755e5f877d83ce5] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + fsdev/virtfs-proxy-helper.c | 27 ++++++++++++++++++++++++-- + hw/9pfs/9p-util.h | 38 +++++++++++++++++++++++++++++++++++++ + 2 files changed, 63 insertions(+), 2 deletions(-) + +diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c +index 5cafcd770..d9511f429 100644 +--- a/fsdev/virtfs-proxy-helper.c ++++ b/fsdev/virtfs-proxy-helper.c +@@ -26,6 +26,7 @@ + #include "qemu/xattr.h" + #include "9p-iov-marshal.h" + #include "hw/9pfs/9p-proxy.h" ++#include "hw/9pfs/9p-util.h" + #include "fsdev/9p-iov-marshal.h" + + #define PROGNAME "virtfs-proxy-helper" +@@ -338,6 +339,28 @@ static void resetugid(int suid, int sgid) + } + } + ++/* ++ * Open regular file or directory. Attempts to open any special file are ++ * rejected. ++ * ++ * returns file descriptor or -1 on error ++ */ ++static int open_regular(const char *pathname, int flags, mode_t mode) ++{ ++ int fd; ++ ++ fd = open(pathname, flags, mode); ++ if (fd < 0) { ++ return fd; ++ } ++ ++ if (close_if_special_file(fd) < 0) { ++ return -1; ++ } ++ ++ return fd; ++} ++ + /* + * send response in two parts + * 1) ProxyHeader +@@ -682,7 +705,7 @@ static int do_create(struct iovec *iovec) + if (ret < 0) { + goto unmarshal_err_out; + } +- ret = open(path.data, flags, mode); ++ ret = open_regular(path.data, flags, mode); + if (ret < 0) { + ret = -errno; + } +@@ -707,7 +730,7 @@ static int do_open(struct iovec *iovec) + if (ret < 0) { + goto err_out; + } +- ret = open(path.data, flags); ++ ret = open_regular(path.data, flags, 0); + if (ret < 0) { + ret = -errno; + } +diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h +index c3526144c..6b44e5f7a 100644 +--- a/hw/9pfs/9p-util.h ++++ b/hw/9pfs/9p-util.h +@@ -13,6 +13,8 @@ + #ifndef QEMU_9P_UTIL_H + #define QEMU_9P_UTIL_H + ++#include "qemu/error-report.h" ++ + #ifdef O_PATH + #define O_PATH_9P_UTIL O_PATH + #else +@@ -112,6 +114,38 @@ static inline void close_preserve_errno(int fd) + errno = serrno; + } + ++/** ++ * close_if_special_file() - Close @fd if neither regular file nor directory. ++ * ++ * @fd: file descriptor of open file ++ * Return: 0 on regular file or directory, -1 otherwise ++ * ++ * CVE-2023-2861: Prohibit opening any special file directly on host ++ * (especially device files), as a compromised client could potentially gain ++ * access outside exported tree under certain, unsafe setups. We expect ++ * client to handle I/O on special files exclusively on guest side. ++ */ ++static inline int close_if_special_file(int fd) ++{ ++ struct stat stbuf; ++ ++ if (fstat(fd, &stbuf) < 0) { ++ close_preserve_errno(fd); ++ return -1; ++ } ++ if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) { ++ error_report_once( ++ "9p: broken or compromised client detected; attempt to open " ++ "special file (i.e. neither regular file, nor directory)" ++ ); ++ close(fd); ++ errno = ENXIO; ++ return -1; ++ } ++ ++ return 0; ++} ++ + static inline int openat_dir(int dirfd, const char *name) + { + return openat(dirfd, name, +@@ -146,6 +180,10 @@ again: + return -1; + } + ++ if (close_if_special_file(fd) < 0) { ++ return -1; ++ } ++ + serrno = errno; + /* O_NONBLOCK was only needed to open the file. Let's drop it. We don't + * do that with O_PATH since fcntl(F_SETFL) isn't supported, and openat() +-- +2.40.0 diff --git a/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3255.patch b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3255.patch new file mode 100644 index 0000000000..661af629b0 --- /dev/null +++ b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3255.patch @@ -0,0 +1,65 @@ +From d921fea338c1059a27ce7b75309d7a2e485f710b Mon Sep 17 00:00:00 2001 +From: Mauro Matteo Cascella <mcascell@redhat.com> +Date: Wed, 2 Aug 2023 12:29:55 +0000 +Subject: [PATCH] ui/vnc-clipboard: fix infinite loop in inflate_buffer + (CVE-2023-3255) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 + Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; + charset=UTF-8 Content-Transfer-Encoding: 8bit +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +A wrong exit condition may lead to an infinite loop when inflating a +valid zlib buffer containing some extra bytes in the `inflate_buffer` +function. The bug only occurs post-authentication. Return the buffer +immediately if the end of the compressed data has been reached +(Z_STREAM_END). + +Fixes: CVE-2023-3255 +Fixes: 0bf41cab ("ui/vnc: clipboard support") +Reported-by: Kevin Denis <kevin.denis@synacktiv.com> +Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com> +Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> +Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> +Message-ID: <20230704084210.101822-1-mcascell@redhat.com> + +CVE: CVE-2023-3255 + +Upstream-Status: Backport [https://github.com/qemu/qemu/commit/d921fea338c1059a27ce7b75309d7a2e485f710b] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + ui/vnc-clipboard.c | 10 ++++------ + 1 file changed, 4 insertions(+), 6 deletions(-) + +diff --git a/ui/vnc-clipboard.c b/ui/vnc-clipboard.c +index 8aeadfaa2..c759be343 100644 +--- a/ui/vnc-clipboard.c ++++ b/ui/vnc-clipboard.c +@@ -50,8 +50,11 @@ static uint8_t *inflate_buffer(uint8_t *in, uint32_t in_len, uint32_t *size) + ret = inflate(&stream, Z_FINISH); + switch (ret) { + case Z_OK: +- case Z_STREAM_END: + break; ++ case Z_STREAM_END: ++ *size = stream.total_out; ++ inflateEnd(&stream); ++ return out; + case Z_BUF_ERROR: + out_len <<= 1; + if (out_len > (1 << 20)) { +@@ -66,11 +69,6 @@ static uint8_t *inflate_buffer(uint8_t *in, uint32_t in_len, uint32_t *size) + } + } + +- *size = stream.total_out; +- inflateEnd(&stream); +- +- return out; +- + err_end: + inflateEnd(&stream); + err: +-- +2.40.0 diff --git a/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3301.patch b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3301.patch new file mode 100644 index 0000000000..977f017ed2 --- /dev/null +++ b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3301.patch @@ -0,0 +1,65 @@ +From a0d7215e339b61c7d7a7b3fcf754954d80d93eb8 Sep 17 00:00:00 2001 +From: Ani Sinha <anisinha@redhat.com> +Date: Wed, 2 Aug 2023 09:25:27 +0000 +Subject: [PATCH] vhost-vdpa: do not cleanup the vdpa/vhost-net structures if + peer nic is present + +When a peer nic is still attached to the vdpa backend, it is too early to free +up the vhost-net and vdpa structures. If these structures are freed here, then +QEMU crashes when the guest is being shut down. The following call chain +would result in an assertion failure since the pointer returned from +vhost_vdpa_get_vhost_net() would be NULL: + +do_vm_stop() -> vm_state_notify() -> virtio_set_status() -> +virtio_net_vhost_status() -> get_vhost_net(). + +Therefore, we defer freeing up the structures until at guest shutdown +time when qemu_cleanup() calls net_cleanup() which then calls +qemu_del_net_client() which would eventually call vhost_vdpa_cleanup() +again to free up the structures. This time, the loop in net_cleanup() +ensures that vhost_vdpa_cleanup() will be called one last time when +all the peer nics are detached and freed. + +All unit tests pass with this change. + +CC: imammedo@redhat.com +CC: jusual@redhat.com +CC: mst@redhat.com +Fixes: CVE-2023-3301 +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128929 +Signed-off-by: Ani Sinha <anisinha@redhat.com> +Message-Id: <20230619065209.442185-1-anisinha@redhat.com> +Reviewed-by: Michael S. Tsirkin <mst@redhat.com> +Signed-off-by: Michael S. Tsirkin <mst@redhat.com> + +CVE: CVE-2023-3301 + +Upstream-Status: Backport [https://github.com/qemu/qemu/commit/a0d7215e339b61c7d7a7b3fcf754954d80d93eb8] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + net/vhost-vdpa.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c +index 2b4b85d8f..8dbe929c1 100644 +--- a/net/vhost-vdpa.c ++++ b/net/vhost-vdpa.c +@@ -158,6 +158,15 @@ err_init: + static void vhost_vdpa_cleanup(NetClientState *nc) + { + VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc); ++ ++ /* ++ * If a peer NIC is attached, do not cleanup anything. ++ * Cleanup will happen as a part of qemu_cleanup() -> net_cleanup() ++ * when the guest is shutting down. ++ */ ++ if (nc->peer && nc->peer->info->type == NET_CLIENT_DRIVER_NIC) { ++ return; ++ } + struct vhost_dev *dev = &s->vhost_net->dev; + + qemu_vfree(s->cvq_cmd_out_buffer); +-- +2.40.0 diff --git a/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3354.patch b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3354.patch new file mode 100644 index 0000000000..b3958ecbf5 --- /dev/null +++ b/poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3354.patch @@ -0,0 +1,88 @@ +From 10be627d2b5ec2d6b3dce045144aa739eef678b4 Mon Sep 17 00:00:00 2001 +From: Daniel P. Berrangé <berrange@redhat.com> +Date: Tue, 12 Sep 2023 06:38:03 +0000 +Subject: [PATCH] io: remove io watch if TLS channel is closed during handshake +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The TLS handshake make take some time to complete, during which time an +I/O watch might be registered with the main loop. If the owner of the +I/O channel invokes qio_channel_close() while the handshake is waiting +to continue the I/O watch must be removed. Failing to remove it will +later trigger the completion callback which the owner is not expecting +to receive. In the case of the VNC server, this results in a SEGV as +vnc_disconnect_start() tries to shutdown a client connection that is +already gone / NULL. + +CVE-2023-3354 +Reported-by: jiangyegen <jiangyegen@huawei.com> +Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> + +CVE: CVE-2023-3354 + +Upstream-Status: Backport [https://gitlab.com/qemu-project/qemu/-/commit/10be627d2b5ec2d6b3dce045144aa739eef678b4] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + include/io/channel-tls.h | 1 + + io/channel-tls.c | 18 ++++++++++++------ + 2 files changed, 13 insertions(+), 6 deletions(-) + +diff --git a/include/io/channel-tls.h b/include/io/channel-tls.h +index 5672479e9..ccd510ade 100644 +--- a/include/io/channel-tls.h ++++ b/include/io/channel-tls.h +@@ -48,6 +48,7 @@ struct QIOChannelTLS { + QIOChannel *master; + QCryptoTLSSession *session; + QIOChannelShutdown shutdown; ++ guint hs_ioc_tag; + }; + + /** +diff --git a/io/channel-tls.c b/io/channel-tls.c +index 4ce890a53..17d73f02e 100644 +--- a/io/channel-tls.c ++++ b/io/channel-tls.c +@@ -195,12 +195,13 @@ static void qio_channel_tls_handshake_task(QIOChannelTLS *ioc, + } + + trace_qio_channel_tls_handshake_pending(ioc, status); +- qio_channel_add_watch_full(ioc->master, +- condition, +- qio_channel_tls_handshake_io, +- data, +- NULL, +- context); ++ ioc->hs_ioc_tag = ++ qio_channel_add_watch_full(ioc->master, ++ condition, ++ qio_channel_tls_handshake_io, ++ data, ++ NULL, ++ context); + } + } + +@@ -215,6 +216,7 @@ static gboolean qio_channel_tls_handshake_io(QIOChannel *ioc, + QIOChannelTLS *tioc = QIO_CHANNEL_TLS( + qio_task_get_source(task)); + ++ tioc->hs_ioc_tag = 0; + g_free(data); + qio_channel_tls_handshake_task(tioc, task, context); + +@@ -374,6 +376,10 @@ static int qio_channel_tls_close(QIOChannel *ioc, + { + QIOChannelTLS *tioc = QIO_CHANNEL_TLS(ioc); + ++ if (tioc->hs_ioc_tag) { ++ g_clear_handle_id(&tioc->hs_ioc_tag, g_source_remove); ++ } ++ + return qio_channel_close(tioc->master, errp); + } + +-- +2.35.5 diff --git a/poky/meta/recipes-devtools/qemu/qemu/qemu-7.0.0-glibc-2.36.patch b/poky/meta/recipes-devtools/qemu/qemu/qemu-7.0.0-glibc-2.36.patch deleted file mode 100644 index abad1cfeeb..0000000000 --- a/poky/meta/recipes-devtools/qemu/qemu/qemu-7.0.0-glibc-2.36.patch +++ /dev/null @@ -1,46 +0,0 @@ -Avoid conflicts between sys/mount.h and linux/mount.h that are seen -with glibc 2.36 - -Source: https://github.com/archlinux/svntogit-packages/blob/packages/qemu/trunk/qemu-7.0.0-glibc-2.36.patch - -Upstream-Status: Pending -Signed-off-by: Khem Raj <raj.khem@gmail.com> ---- a/linux-user/syscall.c -+++ b/linux-user/syscall.c -@@ -95,7 +95,25 @@ - #include <linux/soundcard.h> - #include <linux/kd.h> - #include <linux/mtio.h> -+ -+#ifdef HAVE_SYS_MOUNT_FSCONFIG -+/* -+ * glibc >= 2.36 linux/mount.h conflicts with sys/mount.h, -+ * which in turn prevents use of linux/fs.h. So we have to -+ * define the constants ourselves for now. -+ */ -+#define FS_IOC_GETFLAGS _IOR('f', 1, long) -+#define FS_IOC_SETFLAGS _IOW('f', 2, long) -+#define FS_IOC_GETVERSION _IOR('v', 1, long) -+#define FS_IOC_SETVERSION _IOW('v', 2, long) -+#define FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap) -+#define FS_IOC32_GETFLAGS _IOR('f', 1, int) -+#define FS_IOC32_SETFLAGS _IOW('f', 2, int) -+#define FS_IOC32_GETVERSION _IOR('v', 1, int) -+#define FS_IOC32_SETVERSION _IOW('v', 2, int) -+#else - #include <linux/fs.h> -+#endif - #include <linux/fd.h> - #if defined(CONFIG_FIEMAP) - #include <linux/fiemap.h> ---- a/meson.build -+++ b/meson.build -@@ -1686,6 +1686,8 @@ config_host_data.set('HAVE_OPTRESET', - cc.has_header_symbol('getopt.h', 'optreset')) - config_host_data.set('HAVE_IPPROTO_MPTCP', - cc.has_header_symbol('netinet/in.h', 'IPPROTO_MPTCP')) -+config_host_data.set('HAVE_SYS_MOUNT_FSCONFIG', -+ cc.has_header_symbol('sys/mount.h', 'FSCONFIG_SET_FLAG')) - - # has_member - config_host_data.set('HAVE_SIGEV_NOTIFY_THREAD_ID', |