CVE-2017-1000364

What it actually does

The 4 KB stack guard page can be bypassed by a sufficiently large stack-based memory write, allowing an attacker-controlled contiguous memory region to be reached beyond the guard and corrupting adjacent structures.

Why it matters to the business

Older Linux systems remain exposed to local memory corruption that can lead to privilege escalation or container escape; the issue has been publicly weaponized for years, raising the risk for any unpatched fleet that still runs kernels 4.11.5 or earlier.

How an attack unfolds

An attacker on a local account crafts input or uses a helper binary that forces a stack allocation larger than the 4 KB guard page; the write jumps the guard, lands in a mapped page belonging to another structure or binary, and overwrites return addresses or function pointers to gain code execution.

How to fix it

Upgrade the Linux kernel to a version later than 4.11.5 that restores an adequately sized stack guard page; where an upgrade is not immediately possible, rebuild the kernel with a larger CONFIG_STACK_GUARD_PAGE or apply the vendor back-port that enlarges the guard.

How to confirm the fix worked

Confirm the running kernel is newer than 4.11.5; inspect /proc/self/maps or use the kernel build configuration to verify the stack guard page size is at least 8 KB or greater; re-run any existing stack-clash proof-of-concept binaries to ensure they no longer succeed.

Typical attack path

1. Obtain a local shell on the target host
2. Trigger a large stack allocation via setuid binary, kernel syscall, or user-space program
3. Bypass the undersized guard page and corrupt adjacent memory
4. Hijack control flow to execute attacker-supplied code
5. Escalate privileges or break out of container/sandbox

How to detect it

Review authentication and process-creation logs for unexpected local shells or setuid executions immediately preceding crashes or segfaults; examine kernel or audit logs for unusual stack-size-related faults or mmap activity around the stack region.

What your security team should do

• Prioritize kernel upgrades on all internet-facing or multi-tenant systems still running 4.11.5 or earlier
• Add kernel version checks to vulnerability scanning and asset inventory
• Harden local attack surface by removing unnecessary setuid binaries and enforcing seccomp or container isolation
• Monitor vendor advisories for any remaining distribution-specific back-ports