CVE-2024-26958 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs]
process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have
if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a
nfs_commit_begin(); nfs_commit_end();
Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/26/2026
The vulnerability identified as CVE-2024-26958 represents a use-after-free condition affecting the Linux kernel's Network File System (NFS) implementation, specifically within direct write operations. This flaw manifests as a refcount_t underflow warning that occurs when the nfs_direct_request structure is completed twice in sequence, leading to memory corruption and potential system instability. The issue primarily affects systems utilizing NFS direct I/O operations where asynchronous commit requests are processed concurrently.
The technical root cause stems from improper reference counting management within the NFS direct write completion path. When processing commit requests, the kernel code executes nfs_commit_end() followed by nfs_direct_write_complete() without proper synchronization mechanisms to prevent double completion. This pattern occurs because asynchronous requests may complete out of order, with one commit request finishing before subsequent requests are submitted, resulting in the same nfs_direct_request structure being marked as complete multiple times. The underlying problem demonstrates a classic reference counting error that violates fundamental memory safety principles.
This vulnerability directly maps to CWE-415, which describes double free conditions in software systems, and CWE-416, which covers use-after-free errors. The operational impact of this flaw extends beyond simple memory corruption to potentially enable privilege escalation or denial of service attacks, particularly in high-throughput environments where NFS direct I/O is heavily utilized. The warning appears with sufficient frequency in production systems that it represents a significant stability concern for enterprise deployments relying on NFS storage solutions.
The mitigation strategy involves implementing proper reference counting patterns consistent with the existing nfs_generic_commit_list() usage in __nfs_commit_inode. The fix requires wrapping the commit request processing with nfs_commit_begin() and nfs_commit_end() calls, establishing a consistent completion handling pattern that prevents the double completion scenario. This approach aligns with established kernel development practices and ATT&CK technique T1068, which covers privilege escalation through exploitation of kernel vulnerabilities. The patch demonstrates the importance of proper resource management in kernel-level code and the necessity of maintaining consistent synchronization patterns across complex asynchronous operations. Production testing with a 200-node RocksDB stress test confirmed that the fix resolves the intermittent warning that previously occurred every 10 minutes, with the system now operating stably for several hours without recurrence.