diff --git a/target/linux/generic/pending-6.12/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch b/target/linux/generic/pending-6.12/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch
new file mode 100644
index 00000000000..0c83e9884a9
--- /dev/null
+++ b/target/linux/generic/pending-6.12/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch
@@ -0,0 +1,39 @@
+From ed7fc59a8dde6059bdbb55cf836a32beb4dd26de Mon Sep 17 00:00:00 2001
+From: Paul Spooren <mail@aparcar.org>
+Date: Fri, 25 Sep 2026 09:54:16 +0200
+Subject: [PATCH] powerpc: build the vDSO after the stack protector flags are
+ set
+
+stack_protector_prepare appends the -mstack-protector-guard flags to
+KBUILD_CFLAGS with $(eval) from within its recipe, so the flags only
+reach commands that make starts after that recipe. vdso_prepare builds
+the vDSO from a sibling prerequisite of prepare. Nothing orders the two,
+so the vDSO is built with or without the flags depending on the order in
+which make starts the recipes.
+
+The vDSO is built with -fno-stack-protector, so its code is the same
+either way. GCC records the command line in DW_AT_producer, though, and
+the kernel embeds vdso32.so.dbg with its debug information. Two builds
+of the same kernel therefore differ:
+
+  -GNU C11 14.4.0 ... -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=872 -m32 -g -O2 ...
+  +GNU C11 14.4.0 ... -m32 -g -O2 ...
+
+Make vdso_prepare depend on stack_protector_prepare, so the vDSO is
+always built with the final KBUILD_CFLAGS.
+
+Signed-off-by: Paul Spooren <mail@aparcar.org>
+---
+ arch/powerpc/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/Makefile
++++ b/arch/powerpc/Makefile
+@@ -391,6 +391,7 @@ archheaders:
+ 
+ ifdef CONFIG_STACKPROTECTOR
+ prepare: stack_protector_prepare
++vdso_prepare: stack_protector_prepare
+ 
+ PHONY += stack_protector_prepare
+ stack_protector_prepare: prepare0
diff --git a/target/linux/generic/pending-6.18/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch b/target/linux/generic/pending-6.18/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch
new file mode 100644
index 00000000000..e30f917ea3e
--- /dev/null
+++ b/target/linux/generic/pending-6.18/305-powerpc-build-the-vDSO-after-the-stack-protector-flags.patch
@@ -0,0 +1,39 @@
+From a4b68ad654bedc6b401e648fd359701e62321f79 Mon Sep 17 00:00:00 2001
+From: Paul Spooren <mail@aparcar.org>
+Date: Fri, 25 Sep 2026 09:54:16 +0200
+Subject: [PATCH] powerpc: build the vDSO after the stack protector flags are
+ set
+
+stack_protector_prepare appends the -mstack-protector-guard flags to
+KBUILD_CFLAGS with $(eval) from within its recipe, so the flags only
+reach commands that make starts after that recipe. vdso_prepare builds
+the vDSO from a sibling prerequisite of prepare. Nothing orders the two,
+so the vDSO is built with or without the flags depending on the order in
+which make starts the recipes.
+
+The vDSO is built with -fno-stack-protector, so its code is the same
+either way. GCC records the command line in DW_AT_producer, though, and
+the kernel embeds vdso32.so.dbg with its debug information. Two builds
+of the same kernel therefore differ:
+
+  -GNU C11 14.4.0 ... -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=872 -m32 -g -O2 ...
+  +GNU C11 14.4.0 ... -m32 -g -O2 ...
+
+Make vdso_prepare depend on stack_protector_prepare, so the vDSO is
+always built with the final KBUILD_CFLAGS.
+
+Signed-off-by: Paul Spooren <mail@aparcar.org>
+---
+ arch/powerpc/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/Makefile
++++ b/arch/powerpc/Makefile
+@@ -398,6 +398,7 @@ archheaders:
+ 
+ ifdef CONFIG_STACKPROTECTOR
+ prepare: stack_protector_prepare
++vdso_prepare: stack_protector_prepare
+ 
+ PHONY += stack_protector_prepare
+ stack_protector_prepare: prepare0