CVE-2024-45025

What it actually does

The vulnerability corrupts the full_fds_bits[] bitmap in struct fdtable during copy_fd_bitmaps() when close_range() is called with CLOSE_RANGE_UNSHARE on a shared descriptor table where 'to' exceeds current capacity and 'from' sits just under a block of open descriptors, leaving garbage bits from an incompletely zeroed word.

Why it matters to the business

Applications relying on accurate file descriptor state after fork+close_range operations (common in servers, containers, and privilege separation) may experience incorrect descriptor allocation, leading to resource leaks, failed operations, or unexpected behavior in child processes; high ecosystem prevalence in Linux distributions amplifies operational risk.

How an attack unfolds

An attacker with local code execution triggers close_range(from, ~0U, CLOSE_RANGE_UNSHARE) on a shared fdtable after spawning a child via CLONE_FILES, causing subsequent dup() calls to return descriptors that should be marked closed; threat actor context includes reported Linux kernel resource and out-of-bounds issues exploited in espionage and financially motivated campaigns.

How to fix it

Upgrade the Linux kernel to commit fe5bf14881701119aeeda7cf685f3c226c7380df or later; for github.com/sigstore/cosign update to version 1.10.1 or newer; apply the patch that introduces bitmap_copy_and_expand() and adjusts copy_fd_bitmaps() to operate on word counts.

How to confirm the fix worked

Verify the running kernel contains commit fe5bf14881701119aeeda7cf685f3c226c7380df; execute the added selftest in tools/testing/selftests/core/close_range_test.c; confirm that dup() after the reproducer sequence no longer returns an unexpectedly high descriptor.

Typical attack path

1. Obtain local execution on a vulnerable Linux kernel
2. Share the file descriptor table via CLONE_FILES or similar
3. Open descriptors in a pattern that leaves a full word below 'from'
4. Invoke close_range() with CLOSE_RANGE_UNSHARE where 'to' exceeds max_fds
5. Observe or abuse subsequent descriptor allocation returning unexpected values

How to detect it

Review system logs and application traces for anomalous file descriptor numbers returned by dup() or open() immediately following close_range() calls; inspect kernel oops or warning messages related to fdtable bitmaps; correlate with process creation events involving CLONE_FILES.

What your security team should do

• Prioritize kernel updates on all systems within the CISA-style remediation window if applicable
• Audit workloads that use close_range(CLOSE_RANGE_UNSHARE) or CLONE_FILES for exposure
• Monitor for downstream package updates that include the referenced commit
• Test the reproducer in staging environments before broad deployment