1 files changed, 71 insertions, 0 deletions
diff --git a/meta-openbmc-mods/meta-common/recipes-core/dbus/dbus/CVE-2022-42012.patch b/meta-openbmc-mods/meta-common/recipes-core/dbus/dbus/CVE-2022-42012.patch
new file mode 100644
index 000000000..53b0e92ff
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-core/dbus/dbus/CVE-2022-42012.patch
@@ -0,0 +1,71 @@
+From 236f16e444e88a984cf12b09225e0f8efa6c5b44 Mon Sep 17 00:00:00 2001
+From: Simon McVittie <smcv@collabora.com>
+Date: Fri, 30 Sep 2022 13:46:31 +0100
+Subject: [PATCH] dbus-marshal-byteswap: Byte-swap Unix fd indexes if needed
+
+When a D-Bus message includes attached file descriptors, the body of the
+message contains unsigned 32-bit indexes pointing into an out-of-band
+array of file descriptors. Some D-Bus APIs like GLib's GDBus refer to
+these indexes as "handles" for the associated fds (not to be confused
+with a Windows HANDLE, which is a kernel object).
+
+The assertion message removed by this commit is arguably correct up to
+a point: fd-passing is only reasonable on a local machine, and no known
+operating system allows processes of differing endianness even on a
+multi-endian ARM or PowerPC CPU, so it makes little sense for the sender
+to specify a byte-order that differs from the byte-order of the recipient.
+
+However, this doesn't account for the fact that a malicious sender
+doesn't have to restrict itself to only doing things that make sense.
+On a system with untrusted local users, a message sender could crash
+the system dbus-daemon (a denial of service) by sending a message in
+the opposite endianness that contains handles to file descriptors.
+
+Before this commit, if assertions are enabled, attempting to byteswap
+a fd index would cleanly crash the message recipient with an assertion
+failure. If assertions are disabled, attempting to byteswap a fd index
+would silently do nothing without advancing the pointer p, causing the
+message's type and the pointer into its contents to go out of sync, which
+can result in a subsequent crash (the crash demonstrated by fuzzing was
+a use-after-free, but other failure modes might be possible).
+
+In principle we could resolve this by rejecting wrong-endianness messages
+from a local sender, but it's actually simpler and less code to treat
+wrong-endianness messages as valid and byteswap them.
+
+Thanks: Evgeny Vereshchagin
+Fixes: ba7daa60 "unix-fd: add basic marshalling code for unix fds"
+Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/417
+Resolves: CVE-2022-42012
+Signed-off-by: Simon McVittie <smcv@collabora.com>
+---
+ dbus/dbus-marshal-byteswap.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/dbus/dbus-marshal-byteswap.c b/dbus/dbus-marshal-byteswap.c
+index e9de6f02a..9dd1246f9 100644
+--- a/dbus/dbus-marshal-byteswap.c
++++ b/dbus/dbus-marshal-byteswap.c
+@@ -62,6 +62,7 @@ byteswap_body_helper (DBusTypeReader       *reader,
+         case DBUS_TYPE_BOOLEAN:
+         case DBUS_TYPE_INT32:
+         case DBUS_TYPE_UINT32:
++        case DBUS_TYPE_UNIX_FD:
+           {
+             p = _DBUS_ALIGN_ADDRESS (p, 4);
+             *((dbus_uint32_t*)p) = DBUS_UINT32_SWAP_LE_BE (*((dbus_uint32_t*)p));
+@@ -192,11 +193,6 @@ byteswap_body_helper (DBusTypeReader       *reader,
+           }
+           break;
+ 
+-        case DBUS_TYPE_UNIX_FD:
+-          /* fds can only be passed on a local machine, so byte order must always match */
+-          _dbus_assert_not_reached("attempted to byteswap unix fds which makes no sense");
+-          break;
+-
+         default:
+           _dbus_assert_not_reached ("invalid typecode in supposedly-validated signature");
+           break;
+-- 
+GitLab
+