CVE-2026-31703: writeback: Fix use after free in inode_switch_wbs_work_fn()
In the Linux kernel, the following vulnerability has been resolved:
writeback: Fix use after free in inode_switch_wbs_work_fn()
inode_switch_wbs_work_fn() has a loop like:
wb_get(new_wb);
while (1) {
list = llist_del_all(&new_wb->switch_wbs_ctxs);
/* Nothing to do? */
if (!list)
break;
... process the items ...
}
Now adding of items to the list looks like:
wb_queue_isw()
if (llist_add(&isw->list, &wb->switch_wbs_ctxs))
queue_work(isw_wq, &wb->switch_work);
Because inode_switch_wbs_work_fn() loops when processing isw items, it
can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is
empty. This is a problem because in that case wb can get freed (no isw
items -> no wb reference) while the work is still pending causing
use-after-free issues.
We cannot just fix this by cancelling work when freeing wb because that
could still trigger problematic 0 -> 1 transitions on wb refcount due to
wb_get() in inode_switch_wbs_work_fn(). It could be all handled with
more careful code but that seems unnecessarily complex so let's avoid
that until it is proven that the looping actually brings practical
benefit. Just remove the loop from inode_switch_wbs_work_fn() instead.
That way when wb_queue_isw() queues work, we are guaranteed we have
added the first item to wb->switch_wbs_ctxs and nobody is going to
remove it (and drop the wb reference it holds) until the queued work
runs.
Security readout for executives and security teams
Plain-English summary
A Linux kernel writeback race can leave queued work referencing memory that has already been freed. A low-privilege local user may be able to trigger kernel memory corruption, potentially causing system compromise or crashes. This is important for shared, multi-user, and other systems where untrusted users can execute local code.
Executive priority
Treat as a high-priority kernel update for systems permitting untrusted local code execution. Prioritize shared and multi-user infrastructure, then validate vendor-specific exposure elsewhere. There is no supplied evidence of active exploitation, so urgency should reflect local-access opportunities and business criticality.
Technical view
A race in inode_switch_wbs_work_fn() can leave switch_work pending after switch_wbs_ctxs becomes empty. The associated writeback object may then lose its final reference and be freed before the queued worker runs, producing a use-after-free. The referenced stable fixes remove the processing loop so queued work retains the list-held reference until execution.
Likely exposure
Potentially exposed systems are those running kernels the supplied record marks affected: 6.18, 6.18.25, 7.0.2, and 7.1. Its additional version entry of "0" is ambiguous. Distribution backports may alter exposure, so package-level vendor confirmation is necessary.
Exploitation context
The CVSS vector requires local access and low privileges, with no user interaction. Successful exploitation could affect confidentiality, integrity, and availability. The source bundle reports no KEV listing and provides no evidence of active exploitation or a public exploit.
Researcher notes
The supplied version data is not a clean release range: it includes an ambiguous "0" entry and commit hashes marked unaffected. Multiple stable-tree fixes are referenced, suggesting branch-specific backports. Researchers and vulnerability managers should rely on commit inclusion and distribution advisories rather than version-string comparison alone.
Mitigation direction
Apply the applicable vendor kernel update containing a referenced stable fix.
Follow distribution guidance to activate the corrected kernel.
Until updated, restrict low-privilege local access to affected systems.
Check vendor advisories for package-specific status and backports.
Validation and detection
Inventory running kernel releases across potentially exposed systems.
Compare installed packages with vendor advisories and the supplied affected-version data.
Confirm the deployed build incorporates a referenced fix or vendor backport.
Verify systems run the corrected kernel after maintenance.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-825: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
1ADP providers
10Source links
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-825 · source CWE mapping
Expired Pointer Dereference
Expired Pointer Dereference represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.