Memory Leak Affecting kernel-headers package, versions <0:6.1.77-99.164.amzn2023


Severity

Recommended
high

Based on Amazon 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-AMZN2023-KERNELHEADERS-7642793
  • published7 Aug 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?

Upgrade Amazon-Linux:2023 kernel-headers to version 0:6.1.77-99.164.amzn2023 or higher.
This issue was patched in ALAS2023-2024-517.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-headers package and not the kernel-headers package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 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