CVE-2017-1000255

What it actually does

Local user-controlled signal frame allows sigreturn to supply an attacker-chosen r1 value as the kernel stack pointer during exception entry on PowerPC, causing the kernel to write the signal frame contents into arbitrary kernel memory locations before any oops or panic occurs.

Why it matters to the business

On PowerPC servers running vulnerable kernels, a local attacker can corrupt kernel memory, leading to system instability, denial of service, or potential privilege escalation; the issue affects a subset of high-end enterprise and HPC systems.

How an attack unfolds

An attacker with local unprivileged access crafts a malicious signal frame containing a chosen kernel stack pointer, invokes sigreturn, forces an exception so the kernel uses the supplied r1 value, and the subsequent write of the signal frame overwrites kernel memory; the resulting oops occurs only after the corruption.

How to fix it

Upgrade to a Linux kernel version containing the fix for this transactional memory signal handling issue; alternatively rebuild with CONFIG_PPC_TRANSACTIONAL_MEM=n; apply all vendor-supplied PowerPC kernel updates.

How to confirm the fix worked

Verify kernel version is newer than the vulnerable commit range, confirm CONFIG_PPC_TRANSACTIONAL_MEM is disabled in the running kernel config, and test that crafted signal frames no longer produce memory corruption before an oops.

Typical attack path

1. Obtain local shell as unprivileged user on affected PowerPC system
2. Construct signal frame with attacker-controlled r1 value
3. Execute sigreturn syscall to trigger exception path
4. Kernel writes signal frame into attacker-chosen stack location
5. Observe oops or continued execution with corrupted kernel state

How to detect it

Review dmesg, /var/log/kern.log and systemd journal for PowerPC oops or panic entries that reference signal frames, exception entry, or transactional memory shortly after user process activity; correlate with unusual local process terminations.

What your security team should do

• Apply latest PowerPC kernel packages from the distribution vendor immediately
• Restrict local user access on affected systems until patched
• Add kernel oops monitoring for PowerPC signal-handling exceptions
• Audit systems for the CONFIG_PPC_TRANSACTIONAL_MEM setting