Memory Leak Affecting kernel-debug-devel package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (18th 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 Memory Leak vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL6-KERNELDEBUGDEVEL-6767080
  • published2 May 2024
  • disclosed1 May 2024

Introduced: 1 May 2024

CVE-2024-26972  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

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

NVD Description

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

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

ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path

For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it:

  1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode().
  2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.

CVSS Scores

version 3.1