File fix-upstream-CVE-2022-42012.patch of Package dbus-1-x11.26362

Overview Repositories Revisions Requests Users Attributes Meta

File fix-upstream-CVE-2022-42012.patch of Package dbus-1-x11.26362

commit 236f16e444e88a984cf12b09225e0f8efa6c5b44
Author: Simon McVittie <smcv@collabora.com>
Date:   Fri Sep 30 13:46:31 2022 +0100

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>

Index: dbus-1.12.2/dbus/dbus-marshal-byteswap.c
===================================================================
--- dbus-1.12.2.orig/dbus/dbus-marshal-byteswap.c
+++ dbus-1.12.2/dbus/dbus-marshal-byteswap.c
@@ -61,6 +61,7 @@ byteswap_body_helper (DBusTypeReader
         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));
@@ -188,11 +189,6 @@ byteswap_body_helper (DBusTypeReader
           }
           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;

Places

File fix-upstream-CVE-2022-42012.patch of Package dbus-1-x11.26362

Places