CVE-2023-52672

What it actually does

Race condition in Linux kernel pipe resizing moves the wr_wait wakeup before raising max_usage, so writers on a previously full pipe never wake after the resize unless it is a watch queue.

Why it matters to the business

Affected Linux systems can hang or become unresponsive during pipe resize operations under load, disrupting services and requiring reboots; widespread kernel use increases operational risk.

How an attack unfolds

A local attacker creates or locates a full pipe, triggers a resize that moves the wakeup before the max_usage update, and leaves subsequent writers permanently blocked, producing a denial-of-service condition.

How to fix it

Upgrade the Linux kernel to a version containing commit 162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8 or later; apply vendor-supplied updates as soon as available.

How to confirm the fix worked

Verify the running kernel contains commit 162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8 by inspecting git log or kernel version strings; test pipe resize behavior with reproducer workloads to confirm writers wake correctly.

Typical attack path

1. Obtain local user access on a Linux system
2. Locate or allocate a pipe that is already at capacity
3. Issue a pipe resize operation via fcntl or equivalent
4. Observe that writers remain blocked because the wakeup missed the updated limit

How to detect it

Inspect kernel logs for hung-task warnings or pipe-related stalls; correlate with processes performing fcntl F_SETPIPE_SZ on full pipes.

What your security team should do

• Apply the fixed kernel commit immediately on all production systems
• Prioritize updates for systems that perform frequent pipe resizing or run untrusted local workloads
• Review monitoring for hung tasks or pipe-related stalls while patches are deployed