PT-2026-43851 · Linux · Linux

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-45984

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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().]

Related Identifiers

CVE-2026-45984

Affected Products

Linux