在 2026-9-11 16:43, Martin Storsjö 写道:
On Fri, 11 Sep 2026, LIU Hao wrote:

From 38be1b2300f8647e8db6e9268a643ed5dbf02b77 Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler <[email protected]>
Date: Wed, 9 Sep 2026 14:16:34 +0200
Subject: [PATCH] ssp: prioritize stack guard init constructor

Other libraries might also be running constructors, which themselves are built 
with SSP enabled,
or are calling functions that are.
If those then get ordered befor the ssp constructor, they might crash due to 
the yet to be initialized
__stack_chk_guard.

This at least affects a statically linked glib, which launches a background 
thread in the
libgio constructor.
If the ssp constructor then runs at a random point after, it initializes the 
stack guard, and once
the thread returns from whatever function it's in, it crashes because the stack 
guard changed.

Signed-off-by: Timo Rothenpieler <[email protected]>
---
mingw-w64-crt/ssp/stack_chk_guard.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-crt/ssp/stack_chk_guard.c 
b/mingw-w64-crt/ssp/stack_chk_guard.c
index 499f0033b..adffb537b 100644
--- a/mingw-w64-crt/ssp/stack_chk_guard.c
+++ b/mingw-w64-crt/ssp/stack_chk_guard.c
@@ -10,6 +10,11 @@

uintptr_t __stack_chk_guard = 0;

+#if defined(__GNUC__) && __GNUC__ >= 9 && !defined(__clang__)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+#endif

The !defined(__clang__) part of the ifdef is slightly redundant, as Clang currently identifies as GCC 4.2, so it wouldn't ever pass the rest of the condition. But I guess it's ok for clarity anyway.

@@ -21,7 +26,7 @@ __attribute__((__no_stack_protector__))
         -fstack-protector* options from CFLAGS.
# endif
#endif
-__attribute__((__constructor__))
+__attribute__((constructor(0)))
static void __cdecl init(void)
{
  unsigned int ui;

This looks ok to me.

As discussed in the github PR where this originated (https://github.com/mingw-w64/mingw-w64/pull/186), it could be worth considering calling the constructor even earlier (either through the .CRT$XC<char> sections, or through a direct init call even earlier). But this change in itself should probably be good enough for now.

And as pointed out there, initializing it late isn't a problem in itself unless someone starts a thread, where the start of the thread can use one value of the guard and the end of it uses another.
OK, this change is minimal, so I have pushed this one now.

--
Best regards,
LIU Hao

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to