Answer in brief
CVE-2026-45984 records a High severity (CVSS 7.8) vulnerability in gfs2: Fix use-after-free in iomap inline data write path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-45984 records a High severity (CVSS 7.8) vulnerability in gfs2: Fix use-after-free in iomap inline data write path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <1403989d1b502f4a2c0d0b42ccf1c25748442eff || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <1cae1bafdf9caa9b462b19af06b1a06902e4e142 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <764c3c84b5683e608f43735c803a5f415046686c || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <d87268326b277af3665237ac76a73dd9fa8e21b4 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <87d4954b5c59735a99ea98cb208d47130f6dce7d || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <6d76febba07c40bcf358f63216d36ea68cf1c215 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <815ddd27c0c7171a99fe802fdb19098ddef8b19d || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <faddeb848305e79db89ee0479bb0e33380656321 | 1403989d1b502f4a2c0d0b42ccf1c25748442eff, 1cae1bafdf9caa9b462b19af06b1a06902e4e142, 764c3c84b5683e608f43735c803a5f415046686c, d87268326b277af3665237ac76a73dd9fa8e21b4, 87d4954b5c59735a99ea98cb208d47130f6dce7d, 6d76febba07c40bcf358f63216d36ea68cf1c215, 815ddd27c0c7171a99fe802fdb19098ddef8b19d, faddeb848305e79db89ee0479bb0e33380656321 |
| Linux/Linuxgeneric | 5.2 | Not reported |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 2026
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().]
Quoted source text, attributed separately from HOL analysis.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <1403989d1b502f4a2c0d0b42ccf1c25748442eff || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <1cae1bafdf9caa9b462b19af06b1a06902e4e142 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <764c3c84b5683e608f43735c803a5f415046686c || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <d87268326b277af3665237ac76a73dd9fa8e21b4 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <87d4954b5c59735a99ea98cb208d47130f6dce7d || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <6d76febba07c40bcf358f63216d36ea68cf1c215 || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <815ddd27c0c7171a99fe802fdb19098ddef8b19d || >=d0a22a4b03b8475b7aa3fa41243c26c291407844 <faddeb848305e79db89ee0479bb0e33380656321 | 1403989d1b502f4a2c0d0b42ccf1c25748442eff, 1cae1bafdf9caa9b462b19af06b1a06902e4e142, 764c3c84b5683e608f43735c803a5f415046686c, d87268326b277af3665237ac76a73dd9fa8e21b4, 87d4954b5c59735a99ea98cb208d47130f6dce7d, 6d76febba07c40bcf358f63216d36ea68cf1c215, 815ddd27c0c7171a99fe802fdb19098ddef8b19d, faddeb848305e79db89ee0479bb0e33380656321 |
| Linux/Linuxgeneric | 5.2 | Not reported |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 2026
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().]
Quoted source text, attributed separately from HOL analysis.