Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN738 _____________________________________________________________________ DATE : 09/07/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running libXfont2 versions prior to 2.0.8, X.Org X server versions prior to 21.1.24, Xwayland versions prior to 24.1.13. ===================================================================== https://lists.x.org/archives/xorg-announce/2026-July/003714.html https://lists.x.org/archives/xorg-announce/2026-July/003716.html _____________________________________________________________________ ====================================================================== X.Org Security Advisory: July 08, 2026 Issues in libXfont2 prior to 2.0.8 ====================================================================== Multiple issues have been found in the libXfont2 library published by X.Org for which we are releasing security fixes in libXfont2-2.0.8. * CVE-2026-56001: BitmapScaleBitmaps Integer Overflow Heap Buffer Overflow In libXfont2's BitmapScaleBitmaps() function, a 32-bit variable keeps the number of bytes to allocate. If the value overflows due to excessive per-glyph byte counts, the resulting calloc() allocates a buffer too small for the subsequent operations. An attacker can trigger this by loading a crafted PCF font via SetFontPath + OpenFont at a scale factor that inflates per-glyph byte counts. Fixed in: libXfont2-2.0.8 Fix: https://gitlab.freedesktop.org/xorg/lib/libxfont/-/commit/be0b08e2d354138d3222b4490e2a77c6ee42f778 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30558) * CVE-2026-56002: PCF Font Parsing Heap Buffer Overflow In libXfont2's pcfReadFont() function, the repadded bitmap buffer is allocated using a bitmapSizes[] value read directly from the PCF file without cross-validation against per-glyph metrics. Writing to that array uses the per-glyph metrics from the file also without validation. A malicious PCF font can declare a tiny bitmapSizes[] value (e.g. 16 bytes) for the server's glyph pad index and a per-glyph metrics that exceeds this size, causing a write past the end of the allocation with attacker-controlled content from the PCF BITMAPS payload. No rendering is needed -- the overflow occurs during font parsing itself. Fixed in: libXfont2-2.0.8 Fix: https://gitlab.freedesktop.org/xorg/lib/libxfont/-/commit/b4389e0b1d84a690b819bb27b1439968811a3674 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30559) * CVE-2026-56003: computeProps Property Buffer Heap Buffer Overflow In libXfont2's ComputeScaledProperties() function, a fixed-size property buffer of 70 slots (1120 bytes) is allocated. The source font properties then trigger a write of 1 slot per unscaled match or 2 slots per scaledX/scaledY match, with no bounds check against the buffer capacity. The PCF parser does not deduplicate properties, so a malicious font can include arbitrarily many properties with the same name atom (e.g. 40 duplicate MIN_SPACE entries), exceeding the property buffer. Fixed in: libXfont2-2.0.8 Fix: https://gitlab.freedesktop.org/xorg/lib/libxfont/-/commit/dff957a5158da038a282a59a31fe736702732939 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30560) _____________________________________________________________________ ======================================================================= X.Org Security Advisory: July 08, 2026 Issues in X.Org X server prior to xorg-server-21.1.24 and Xwayland prior to xwayland-24.1.13 ======================================================================= Multiple issues have been found in the X server and Xwayland implementations published by X.Org for which we are releasing security fixes for in xorg-server-21.1.24 and xwayland-24.1.13. * CVE-2026-55999: glamor Font Atlas Heap Buffer Overflow glamor_font_get() builds a per-font texture atlas by laying out every glyph in the font into a single backing buffer. It computes the slot dimensions from the font's declared maxbounds, but copies each per-glyph bitmap using the individual glyph's metrics (GLYPHHEIGHTPIXELS / GLYPHWIDTHBYTES macros). There is no check that maxbounds actually bounds the per-glyph values. When the font is loaded from a malicious PCF file whose per-glyph metrics exceed the file's maxbounds, the per-glyph memcpy writes far beyond the heap-allocated slot, producing a heap buffer overflow with attacker-controlled extent and attacker-controlled content. An authenticated X client can trigger this by using SetFontPath to add a directory containing a crafted PCF font, loading the font with OpenFont, and drawing text on a glamor-backed drawable. Only servers using the glamor acceleration backend (Xorg with modesetting driver, Xwayland) are affected. Fixed in: xorg-server-21.1.24 and xwayland-24.1.13 Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/fbf7bac22e2c6bd627fb042742a23318263edae1 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30498) * CVE-2026-56000: GLX contextTags Use-After-Free in CommonMakeCurrent() **IMPORTANT:** This issue was reported against 21.1.16 but we've been unable to reproduce it on that release. It is present on the main and the discontinued master branch and in Xwayland. Distributions that backported upstream commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3 to 21.1.x are definitely affected. CommonMakeCurrent() in the GLX dispatch layer captures a pointer into the per-client cl->contextTags array by calling GlxLookupContextTag(). This returns a direct pointer into an array later realloced. If realloc() moves the buffer to a new location, the previously captured oldTag pointer becomes dangling. The subsequent GlxFreeContextTag(oldTag) then writes zeros into freed heap memory (use-after-free). Five fields are zeroed at fixed offsets (16, 24, 32, 36, 40 bytes) within the stale slot. A malicious client can force the realloc by creating 16 GLX contexts with MakeCurrent(oldContextTag=0) to fill all tag slots to capacity, then issuing a 17th MakeCurrent with a non-zero oldContextTag. This triggers the realloc while oldTag points into the old buffer. The attack requires only 34 X11 requests (17 CreateContext + 17 MakeCurrent) from a single client. Fixed in: xorg-server-21.1.24 and xwayland-24.1.13 Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/2779affbdb4354e894f490e56f962527d6125043 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30561) _____________________________________________________________________ ======================================================================= X.Org Security Advisory: July 08, 2026 Issues in X.Org X server prior to xorg-server-21.1.24 and Xwayland prior to xwayland-24.1.13 ======================================================================= Multiple issues have been found in the X server and Xwayland implementations published by X.Org for which we are releasing security fixes for in xorg-server-21.1.24 and xwayland-24.1.13. * CVE-2026-55999: glamor Font Atlas Heap Buffer Overflow glamor_font_get() builds a per-font texture atlas by laying out every glyph in the font into a single backing buffer. It computes the slot dimensions from the font's declared maxbounds, but copies each per-glyph bitmap using the individual glyph's metrics (GLYPHHEIGHTPIXELS / GLYPHWIDTHBYTES macros). There is no check that maxbounds actually bounds the per-glyph values. When the font is loaded from a malicious PCF file whose per-glyph metrics exceed the file's maxbounds, the per-glyph memcpy writes far beyond the heap-allocated slot, producing a heap buffer overflow with attacker-controlled extent and attacker-controlled content. An authenticated X client can trigger this by using SetFontPath to add a directory containing a crafted PCF font, loading the font with OpenFont, and drawing text on a glamor-backed drawable. Only servers using the glamor acceleration backend (Xorg with modesetting driver, Xwayland) are affected. Fixed in: xorg-server-21.1.24 and xwayland-24.1.13 Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/fbf7bac22e2c6bd627fb042742a23318263edae1 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30498) * CVE-2026-56000: GLX contextTags Use-After-Free in CommonMakeCurrent() **IMPORTANT:** This issue was reported against 21.1.16 but we've been unable to reproduce it on that release. It is present on the main and the discontinued master branch and in Xwayland. Distributions that backported upstream commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3 to 21.1.x are definitely affected. CommonMakeCurrent() in the GLX dispatch layer captures a pointer into the per-client cl->contextTags array by calling GlxLookupContextTag(). This returns a direct pointer into an array later realloced. If realloc() moves the buffer to a new location, the previously captured oldTag pointer becomes dangling. The subsequent GlxFreeContextTag(oldTag) then writes zeros into freed heap memory (use-after-free). Five fields are zeroed at fixed offsets (16, 24, 32, 36, 40 bytes) within the stale slot. A malicious client can force the realloc by creating 16 GLX contexts with MakeCurrent(oldContextTag=0) to fill all tag slots to capacity, then issuing a 17th MakeCurrent with a non-zero oldContextTag. This triggers the realloc while oldTag points into the old buffer. The attack requires only 34 X11 requests (17 CreateContext + 17 MakeCurrent) from a single client. Fixed in: xorg-server-21.1.24 and xwayland-24.1.13 Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/2779affbdb4354e894f490e56f962527d6125043 Found by: Anonymous working with Trend Micro Zero Day Initiative. (ZDI-CAN-30561) ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================