Loading...
Loading...
When running the mongodb/mongodb-community-server and mongo 8.x Docker images on AMD strix halo with a 6.19.0-6-generic kernel, the mongod process boots successfully but silently crashes with Exit Code 139 (SIGSEGV) exactly ~30 seconds later. There is no stack trace printed to the MongoDB logs, and the host dmesg / journalctl ring buffer is entirely empty. The process simply vanishes. The crash is caused by a hardware-enforced Control-flow Enforcement Technology (CET) trap, specifically AMD's Shadow Stacks (user_shstk). The host CPU supports user_shstk. The container's userland (Ubuntu 24.04) has a glibc that enables Shadow Stacks by default if the underlying hardware supports it. At the ~30-second mark, MongoDB spins up background threads (likely LogicalSessionCacheReap / LogicalSessionCacheRefresh). The C++ coroutines used by MongoDB perform a context switch (stack pivoting). The CPU detects the stack pointer jump, assumes it is a Return-Oriented Programming (ROP) attack, and executes a hardware-level SIGSEGV. Because the hardware locks the stack, MongoDB's internal C++ crash handler double-faults and fails to print a stack trace, resulting in a completely silent death.
JIRAUSER1290251 commented on Wed, 25 Feb 2026 00:32:59 +0000: it was getting late so i went to bed. I've just had a look at mongo versions and it looks like this issue was introduced in mongod `8.0.5` kralos@strix:~$ for VER in "8.2" "8.0.9" "8.0.8" "8.0.6" "8.0.5" "8.0.4" "8.0.3" "8.0.1" "8.0.0" "7.0" "6.0" "5.0"; do docker run -d --name="mongo-$VER" "mongo:$VER" done 3e9ee0400b8f7d868f3df8050f0bfbb7e11c6748b81d73ce94cb7a327a852819 d86b657fa8619d8c52e3b2b6960cc28fd47e65e81cfa397e544abbe16cc31e77 9763a8ab6346d3fea069d12a9af5d4745958cb470cae775359fa08ef164014ad 867f4b300e5c31cf6fa3ca7a38e586028be85796e2d0f834507f594f63a5809b ff7d145c0e600c0ae8ab493f6608b4bd7928b5ccc8eb2bb32bb88f9fd30fde56 eb9ffe3e7f0dcb5259235dc47b87acd32352c16665a9b75f33d1b5ae1527d4c6 f12205578956ae7ae21a1437f8060118ff6c63a9179a745202ee4bb877d0b435 90646373d1176e3540c48dfa137acf47c88d398896ea2072ae69a7737719bde0 dc78cbcd20338dfce238d56ce7fa0779a9ecfc6853ba24e7a5e00f09a7d74680 552772181fd45956410a9f0d8134f1ceeff372e6467f364f380c5cb99799513f 5edb40e1c58a8cbbd43a114b0b261b3d5bc998fbcbaf72269f891b338eda8da3 653f783dfbb30c543a6a2ecb4f0fce4ab25ee96f379fc73832568b7aa957e8b4 kralos@strix:~$ docker ps -a | grep -E '(CONTAINER|mongo)' CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 653f783dfbb3 mongo:5.0 "docker-entrypoint.s…" 14 seconds ago Up 14 seconds 27017/tcp mongo-5.0 5edb40e1c58a mongo:6.0 "docker-entrypoint.s…" 14 seconds ago Up 14 seconds 27017/tcp mongo-6.0 552772181fd4 mongo:7.0 "docker-entrypoint.s…" 15 seconds ago Up 14 seconds 27017/tcp mongo-7.0 dc78cbcd2033 mongo:8.0.0 "docker-entrypoint.s…" 15 seconds ago Up 14 seconds 27017/tcp mongo-8.0.0 90646373d117 mongo:8.0.1 "docker-entrypoint.s…" 15 seconds ago Up 14 seconds 27017/tcp mongo-8.0.1 f12205578956 mongo:8.0.3 "docker-entrypoint.s…" 15 seconds ago Up 14 seconds 27017/tcp mongo-8.0.3 eb9ffe3e7f0d mongo:8.0.4 "docker-entrypoint.s…" 15 seconds ago Up 15 seconds 27017/tcp mongo-8.0.4 ff7d145c0e60 mongo:8.0.5 "docker-entrypoint.s…" 15 seconds ago Up 15 seconds 27017/tcp mongo-8.0.5 867f4b300e5c mongo:8.0.6 "docker-entrypoint.s…" 15 seconds ago Up 15 seconds 27017/tcp mongo-8.0.6 9763a8ab6346 mongo:8.0.8 "docker-entrypoint.s…" 15 seconds ago Up 15 seconds 27017/tcp mongo-8.0.8 d86b657fa861 mongo:8.0.9 "docker-entrypoint.s…" 15 seconds ago Up 15 seconds 27017/tcp mongo-8.0.9 3e9ee0400b8f mongo:8.2 "docker-entrypoint.s…" 16 seconds ago Up 15 seconds 27017/tcp mongo-8.2 kralos@strix:~$ docker ps -a | grep -E '(CONTAINER|mongo)' CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 653f783dfbb3 mongo:5.0 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-5.0 5edb40e1c58a mongo:6.0 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-6.0 552772181fd4 mongo:7.0 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-7.0 dc78cbcd2033 mongo:8.0.0 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-8.0.0 90646373d117 mongo:8.0.1 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-8.0.1 f12205578956 mongo:8.0.3 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-8.0.3 eb9ffe3e7f0d mongo:8.0.4 "docker-entrypoint.s…" About a minute ago Up About a minute 27017/tcp mongo-8.0.4 ff7d145c0e60 mongo:8.0.5 "docker-entrypoint.s…" About a minute ago Exited (139) 33 seconds ago mongo-8.0.5 867f4b300e5c mongo:8.0.6 "docker-entrypoint.s…" About a minute ago Exited (139) 33 seconds ago mongo-8.0.6 9763a8ab6346 mongo:8.0.8 "docker-entrypoint.s…" About a minute ago Exited (139) 33 seconds ago mongo-8.0.8 d86b657fa861 mongo:8.0.9 "docker-entrypoint.s…" About a minute ago Exited (139) 34 seconds ago mongo-8.0.9 3e9ee0400b8f mongo:8.2 "docker-entrypoint.s…" About a minute ago Exited (139) 34 seconds ago mongo-8.2 kralos@strix:~$
Provision an AMD Zen 4/Zen 5 machine with user_shstk enabled in the kernel (e.g., Ubuntu 24.04/26.04, Kernel 6.8+). I'm using a Ryzen 395 with 6.19.0-6-generic Run mongod from either mongo or mongodb/mongodb-community-server: docker run --name mongo -d mongo:8.2.5 Wait ~30-35 seconds. `docker inspect` will show the container Exited (139). I've only validated this issue on docker so far, if anyone else has a modern CPU and kernel they should re-validate from a native source build of mongod. I might test this later if I get some more spare time. Workaround: The crash can be prevented by passing an environment variable to disable Shadow Stacks in glibc before mongod boots: docker run -d \ --env GLIBC_TUNABLES="glibc.cpu.hwcaps=-SHSTK" \ mongo:8.2.5 With -SHSTK applied, the container remains perfectly stable. (Note: using glibc.pthread.rseq=0 does not fix this issue, proving it is a CET/Shadow Stack fault, not a TCMalloc rseq fault). Note for docker maintainers The mongodb/mongodb-community-server image masks this exit code due to a flawed Python entrypoint wrapper returning 0, but the community mongo image correctly propagates the 139 exit code via its exec gosu implementation). Short term fix Update the official Dockerfiles to permanently inject ENV GLIBC_TUNABLES="glibc.cpu.hwcaps=-SHSTK" into the environment to SIGSEGV/CET on modern hardware. Long term fix Refactor MongoDB's C++ coroutine context-switching logic to be CET-compliant (utilizing incsspq / rstorssp instructions) so it does not trigger Shadow Stack hardware faults. Yep... easy huh
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.