Skip to main content

Linux Kernel CVE-2026-45984

| EUVDEUVD-2026-32269 HIGH
Use After Free (CWE-416)
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-c7gf-37rm-rpg6
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
HIGH
qualitative
Red Hat
7.0 HIGH
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
May 30, 2026 - 11:34 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.8 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:17 nvd
HIGH 7.8

DescriptionCVE.org

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

  1. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)
  2. Calls release_metapath() which calls brelse(dibh), dropping refcount

to 0

  1. kswapd reclaims the page (~39ms later in the syzbot report)
  2. iomap_write_end_inline() tries to memcpy() to iomap->inline_data
  3. 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().]

AnalysisAI

Local privilege escalation potential in the Linux kernel's GFS2 filesystem stems from a use-after-free in the inline data write path of gfs2_iomap_begin(), where the inode buffer head is released before iomap->inline_data is consumed by iomap_write_end_inline(). Local users with the ability to write to a GFS2-backed filesystem can trigger memory corruption via a freed page that kswapd has since reclaimed. No public exploit identified at time of analysis, EPSS probability is very low (0.02%), and the issue is not listed in CISA KEV, but vendor patches across multiple stable trees are available.

Technical ContextAI

The flaw lives in fs/gfs2/bmap.c in the GFS2 (Global File System 2) clustered/shared-disk filesystem implementation. GFS2 supports inline data - small files whose contents fit inside the inode block itself - and uses the generic iomap framework to mediate read/write to that area. In gfs2_iomap_begin(), the inode's buffer head (dibh) is obtained via gfs2_meta_inode_buffer(), and iomap->inline_data is set to point into dibh->b_data + sizeof(struct gfs2_dinode). However, release_metapath() then calls brelse(dibh), dropping its refcount to zero while iomap->inline_data still references that buffer's memory. When kswapd reclaims the page (observed at ~39ms in the syzbot reproducer trace), a subsequent memcpy() in iomap_write_end_inline() writes into freed memory - a classic CWE-416 (Use After Free), which the source CWE field is reported as N/A but is unambiguous from the patch description. The fix stores dibh in iomap->private and takes an extra get_bh() reference in gfs2_iomap_begin(), releasing it in gfs2_iomap_end() once the inline write has finished.

RemediationAI

Vendor-released patches are available: upgrade to Linux 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, or the 7.0 release matching your stable series, using the upstream stable commits listed at https://git.kernel.org/stable/c/ (e.g., 815ddd27c0c7171a99fe802fdb19098ddef8b19d and the seven sibling commits) or your distribution's backported kernel package. If immediate kernel patching is infeasible, the practical compensating control is to avoid mounting GFS2 filesystems and to unmount any existing GFS2 mounts on exposed hosts, since the use-after-free is reachable only via the GFS2 inline-data write path; this trades off the loss of GFS2 cluster-storage functionality for those systems. Restricting write access to GFS2 mount points to trusted users only (via mount options, namespace isolation, or removing untrusted local accounts and containers from hosts that mount GFS2) further narrows the local-attacker surface while waiting for the patched kernel to be rolled out. Track the EUVD record at https://nvd.nist.gov/vuln/detail/CVE-2026-45984 for any additional vendor guidance.

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-45984 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy