Use After Free Affecting kernel-source package, versions <6.12.0-160000.35.1


Severity

Recommended
0.0
high
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.13% (3rd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES1600-KERNELSOURCE-17355548
  • published17 Jun 2026
  • disclosed15 Jun 2026

Introduced: 15 Jun 2026

NewCVE-2026-45984  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 kernel-source to version 6.12.0-160000.35.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-source package and not the kernel-source package as distributed by SLES. See How to fix? for SLES:16.0.0 relevant fixed versions and status.

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

CVSS Base Scores

version 3.1