Incorrect Ownership Assignment Affecting kernel-debug-devel-matched package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.21% (12th 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 IDSNYK-RHEL10-KERNELDEBUGDEVELMATCHED-18923943
  • published19 Aug 2026
  • disclosed15 Aug 2026

Introduced: 15 Aug 2026

NewCVE-2026-72379  (opens in a new tab)
CWE-708  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:10 kernel-debug-devel-matched.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-debug-devel-matched package and not the kernel-debug-devel-matched package as distributed by RHEL. See How to fix? for RHEL:10 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid

vfs_tmpfile() never checked that the caller's fsuid and fsgid map into the filesystem. On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1.

Every other creation path already refuses this: may_o_create() (O_CREAT) and may_create_dentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot be created with an owner the filesystem cannot represent. An O_TMPFILE is no exception: it is created I_LINKABLE and linkat(2) can splice it into the namespace afterwards, so the same guarantee must hold.

Add the missing fsuidgid_has_mapping() check to vfs_tmpfile(). On a non-idmapped mount the caller's fs{u,g}id always map in the superblock's user namespace, so this is a no-op there and only takes effect on an idmapped mount that does not map the caller. It applies to every filesystem that sets FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer tmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open().

CVSS Base Scores

version 3.1