Skip to main content
VulnerabilityPublished Updated

CVE-2026-45984: Linux kernel · gfs2: Fix use-after-free in iomap inline data write path

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in faddeb848305e79db89ee0479bb0e33380656321 : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:18 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in faddeb848305e79db89ee0479bb0e33380656321, d87268326b277af3665237ac76a73dd9fa8e21b4, 1403989d1b502f4a2c0d0b42ccf1c25748442eff +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < faddeb848305e79db89ee0479bb0e33380656321
Fixed in
  • faddeb848305e79db89ee0479bb0e33380656321
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < d87268326b277af3665237ac76a73dd9fa8e21b4
Fixed in
  • d87268326b277af3665237ac76a73dd9fa8e21b4
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < 1403989d1b502f4a2c0d0b42ccf1c25748442eff
Fixed in
  • 1403989d1b502f4a2c0d0b42ccf1c25748442eff
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < 815ddd27c0c7171a99fe802fdb19098ddef8b19d
Fixed in
  • 815ddd27c0c7171a99fe802fdb19098ddef8b19d
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < 764c3c84b5683e608f43735c803a5f415046686c
Fixed in
  • 764c3c84b5683e608f43735c803a5f415046686c
LinuxLinuxAffected
  • ≥ d0a22a4b03b8475b7aa3fa41243c26c291407844, < 87d4954b5c59735a99ea98cb208d47130f6dce7d
Fixed in
  • 87d4954b5c59735a99ea98cb208d47130f6dce7d

Description

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().]

References

Community reviews

Loading reviews…