xorg-x11-server-Xwayland/SOURCES/0008-glx-Call-XACE-hooks-on...

62 lines
2.1 KiB
Diff

From 4093057b98bc5a178f130c9ba6b0b28385e24ae5 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 6 Dec 2023 12:09:41 +0100
Subject: [PATCH xserver 8/9] glx: Call XACE hooks on the GLX buffer
The XSELINUX code will label resources at creation by checking the
access mode. When the access mode is DixCreateAccess, it will call the
function to label the new resource SELinuxLabelResource().
However, GLX buffers do not go through the XACE hooks when created,
hence leaving the resource actually unlabeled.
When, later, the client tries to create another resource using that
drawable (like a GC for example), the XSELINUX code would try to use
the security ID of that object which has never been labeled, get a NULL
pointer and crash when checking whether the requested permissions are
granted for subject security ID.
To avoid the issue, make sure to call the XACE hooks when creating the
GLX buffers.
Credit goes to Donn Seeley <donn@xmission.com> for providing the patch.
CVE-2024-0408
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit e5e8586a12a3ec915673edffa10dc8fe5e15dac3)
---
glx/glxcmds.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index fc26a2e34..1e46d0c72 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -48,6 +48,7 @@
#include "indirect_util.h"
#include "protocol-versions.h"
#include "glxvndabi.h"
+#include "xace.h"
static char GLXServerVendorName[] = "SGI";
@@ -1392,6 +1393,13 @@ DoCreatePbuffer(ClientPtr client, int screenNum, XID fbconfigId,
if (!pPixmap)
return BadAlloc;
+ err = XaceHook(XACE_RESOURCE_ACCESS, client, glxDrawableId, RT_PIXMAP,
+ pPixmap, RT_NONE, NULL, DixCreateAccess);
+ if (err != Success) {
+ (*pGlxScreen->pScreen->DestroyPixmap) (pPixmap);
+ return err;
+ }
+
/* Assign the pixmap the same id as the pbuffer and add it as a
* resource so it and the DRI2 drawable will be reclaimed when the
* pbuffer is destroyed. */
--
2.43.0