CVE-2024-42265

What it actually does

Speculative execution in do_dup2() can fetch fdt->fd[fd] on a mispredicted path even after bounds checks, allowing the same class of invalid file pointer dereference previously addressed in close_fd().

Why it matters to the business

Local users on affected Linux kernels can trigger kernel crashes or denial of service, reducing system availability and requiring reboots or restarts of affected workloads.

How an attack unfolds

An attacker with local code execution crafts a sequence of file descriptor operations that trains the branch predictor to mispredict the fd bounds check in do_dup2(); the resulting speculative load of an out-of-bounds or freed file pointer leads to a kernel oops or memory corruption when the speculation is later discarded.

How to fix it

Upgrade the Linux kernel to a version containing commit ed42e8ff509d2a61c6642d1825032072dab79f26 or later stable releases that apply the array_index_nospec() protection in do_dup2().

How to confirm the fix worked

Verify the running kernel contains the referenced commit or a backport; confirm the fix by inspecting the do_dup2() implementation for array_index_nospec(fd, fdt->max_fds) usage and test that the previously exploitable misprediction path is no longer reachable.

Typical attack path

1. Obtain local user or container access on a vulnerable kernel
2. Open multiple file descriptors and perform operations that bias the branch predictor
3. Call dup2() with an fd value that passes the architectural check but triggers misprediction
4. Trigger the speculative dereference of fdt->fd[fd] leading to kernel fault
5. Observe system crash or attempt to leverage resulting memory corruption for further privilege escalation

How to detect it

Review kernel logs (dmesg, /var/log/kern.log, journalctl) for oops or panic messages referencing do_dup2, file descriptor tables, or speculative execution paths around file close/dup operations; correlate with process activity that manipulates many file descriptors.

What your security team should do

• Prioritize kernel upgrades on all systems that accept untrusted local code or run multi-tenant workloads
• Apply the fix to long-lived containers and virtual machines first
• Monitor vendor security advisories for distribution-specific backports
• Harden systems by restricting unprivileged local access where feasible until patches are deployed