summaryrefslogtreecommitdiff
path: root/poky/meta/recipes-devtools/qemu/qemu
diff options
context:
space:
mode:
Diffstat (limited to 'poky/meta/recipes-devtools/qemu/qemu')
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch2
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch75
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch171
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3255.patch65
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3301.patch65
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/CVE-2023-3354.patch88
-rw-r--r--poky/meta/recipes-devtools/qemu/qemu/qemu-7.0.0-glibc-2.36.patch46
7 files changed, 465 insertions, 47 deletions
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',