Hi Martin,
Yes, you are right.
When using the gcc -fstack-protector-strong flag, the final executables
are broken and will not even start, crashing before entering the main function.
It just prints:
*** stack smashing detected ***: terminated
Regards,
Igor
PS. Below is the updated patch.
---
From 64b5a6d9486b8ed5ee5c17e5f14e94f41618dbfd Mon Sep 17 00:00:00 2001
From: Igor Kostenko <work.ker...@gmail.com>
Date: Thu, 3 Jul 2025 19:02:20 +0200
Subject: [PATCH v3] crt/ssp: fix stack smashing protection bootstrapping
Fix stack protection bootstrapping issue where the guard initialization
function itself triggers false positive stack overflow detection.
This issue occurs when the mingw-w64 CRT library is built with GCC's
-fstack-protector-strong flag, which effectively renders any resulting
binary (whether statically or dynamically linked) corrupted. The final
binary crashes during startup, before it even reaches the main function.
The problem is that the init() function starts with __stack_chk_guard = 0
but initializes it to a random value, causing the stack protection check
to always fail (0 != random) at function exit.
By introducing attribute __no_stack_protector__ we prevent early testing
of the uninitialized guard value.
Signed-off-by: Igor Kostenko <work.ker...@gmail.com>
---
mingw-w64-crt/ssp/stack_chk_guard.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/ssp/stack_chk_guard.c
b/mingw-w64-crt/ssp/stack_chk_guard.c
index 3ff22e020..be43d8c7e 100644
--- a/mingw-w64-crt/ssp/stack_chk_guard.c
+++ b/mingw-w64-crt/ssp/stack_chk_guard.c
@@ -10,7 +10,11 @@
void *__stack_chk_guard;
-static void __cdecl __attribute__((__constructor__)) init(void)
+// This function requires `no_stack_protector` because it changes the
+// value of `__stack_chk_guard`, causing stack checks to fail before
+// returning from this function.
+__attribute__((__constructor__, __no_stack_protector__))
+static void __cdecl init(void)
{
unsigned int ui;
if (__stack_chk_guard != 0)
--
2.24.0.windows.2
чт, 3 лип. 2025 р. о 21:57 Martin Storsjö <mar...@martin.st> пише:
>
> On Thu, 3 Jul 2025, Igor Kostenko wrote:
>
> > Hi LIU Hao,
> > I've borrowed the term 'canary' from the few documentation bits.
> > https://www.redhat.com/en/blog/security-technologies-stack-smashing-protection-stackguard
> > https://lwn.net/Articles/584225/
> > https://wiki.osdev.org/Stack_Smashing_Protector
> > But I used it too loosely.
> >
> > The updated patch is below:
> >
> > ---
> >
> > From 6ea065be6a832a8359b77c373521a0bcbbfa85d6 Mon Sep 17 00:00:00 2001
> > From: Igor Kostenko <work.ker...@gmail.com>
> > Date: Thu, 3 Jul 2025 19:02:20 +0200
> > Subject: [PATCH v2] crt/ssp: disable premature stack protection at canary
> > init
> >
> > Fix stack protection bootstrapping issue where the canary initialization
> > function itself triggers false positive stack overflow detection.
> >
> > Changes in v2:
> > - Shorten init function definition
> > - Rewrite the description
> >
> > Signed-off-by: Igor Kostenko <work.ker...@gmail.com>
> > ---
> > mingw-w64-crt/ssp/stack_chk_guard.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> If I understand things correctly - this is an issue if you compile this
> file (or the whole mingw-w64-crt) with -fstack-protector-strong or similar
> - which would explain why others haven't run into it so far. Is that
> right?
>
> That's quite relevant context here, which should be pointed out in the
> commit message.
>
> Other than that, the change looks reasonable (but I haven't tested it).
>
> // Martin
>
>
>
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
