CVE-2026-45984: gfs2: Fix use-after-free in iomap inline data write path
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in iomap inline data write path
The inline data buffer head (dibh) is being released prematurely in
gfs2_iomap_begin() via release_metapath() while iomap->inline_data
still points to dibh->b_data. This causes a use-after-free when
iomap_write_end_inline() later attempts to write to the inline data
area.
The bug sequence:
1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode
metadata into dibh
2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)
3. Calls release_metapath() which calls brelse(dibh), dropping refcount
to 0
4. kswapd reclaims the page (~39ms later in the syzbot report)
5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data
6. KASAN detects use-after-free write to freed memory
Fix by storing dibh in iomap->private and incrementing its refcount
with get_bh() in gfs2_iomap_begin(). The buffer is then properly
released in gfs2_iomap_end() after the inline write completes,
ensuring the page stays alive for the entire iomap operation.
Note: A C reproducer is not available for this issue. The fix is based
on analysis of the KASAN report and code review showing the buffer head
is freed before use.
[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid
leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
Security readout for executives and security teams
Plain-English summary
CVE-2026-45984 is a Linux kernel memory-safety flaw in GFS2. A local authenticated user could trigger a use-after-free during inline-data writes, potentially causing denial of service or broader kernel compromise. The sources show patches and Red Hat advisories, but no evidence of active exploitation.
Executive priority
Treat as high priority for Linux servers using GFS2 or allowing local shell access. It is not internet-remote based on the provided vector, but kernel memory corruption can have severe business impact if reachable.
Technical view
GFS2 releases an inline data buffer head too early in gfs2_iomap_begin(), while iomap->inline_data still references freed memory. Later inline write completion can write through that stale pointer. The fix keeps a buffer-head reference in iomap->private and releases it in gfs2_iomap_end().
Likely exposure
Exposure is most relevant to Linux systems running affected kernels with GFS2 available or mounted, especially where local authenticated users can write to GFS2 filesystems. Systems not using GFS2 are less likely to be reachable, but should still follow vendor kernel guidance.
Exploitation context
The CVSS vector is local, low complexity, requires low privileges, and requires no user interaction. The source bundle states no C reproducer is available and KEV is false, so active exploitation is not established by the provided evidence.
Researcher notes
The public description attributes the bug to KASAN analysis and code review, not a standalone reproducer. Version mapping in the bundle includes upstream stable commits and vendor advisories; use those authoritative mappings before declaring a host affected or fixed.
Mitigation direction
Apply kernel updates from your Linux vendor or stable kernel branch.
Prioritize Red Hat errata where Red Hat kernels are deployed.
Restrict untrusted local user access on systems using GFS2.
Disable or avoid mounting GFS2 where it is not operationally required.
Track vendor advisories for exact affected package mappings.
Validation and detection
Inventory Linux hosts for kernel version, vendor package, and GFS2 usage.
Confirm installed kernels include the referenced upstream or vendor fix.
Check Red Hat advisory applicability for affected RHEL environments.
Verify GFS2 is not mounted where it is unnecessary.
Document systems deferred from patching and compensating controls.
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-826: 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
18Source 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-826 · source CWE mapping
Premature Release of Resource During Expected Lifetime
Premature Release of Resource During Expected Lifetime represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.