Linux Kernel up to 5.15.45/5.17.13/5.18.2 crash_prepare_elf64_headers memory leak

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 5.0 | $0-$5k | 0.00 |
Summary
A vulnerability identified as critical has been detected in Linux Kernel up to 5.15.45/5.17.13/5.18.2. The impacted element is the function crash_prepare_elf64_headers. Performing a manipulation results in memory leak.
This vulnerability is reported as CVE-2022-49546. No exploit exists.
You should upgrade the affected component.
Details
A vulnerability classified as critical has been found in Linux Kernel up to 5.15.45/5.17.13/5.18.2. This affects the function crash_prepare_elf64_headers. The manipulation with an unknown input leads to a memory leak vulnerability. CWE is classifying the issue as CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. This is going to have an impact on availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [] __vmalloc_node_range+0x101/0x170 [] __vmalloc_node+0xb4/0x160 [] crash_prepare_elf64_headers+0x8e/0xcd0 [] crash_load_segments+0x260/0x470 [] bzImage64_load+0x814/0xad0 [] arch_kexec_kernel_image_load+0x1be/0x2a0 [] kimage_file_alloc_init+0x2ec/0x5a0 [] __do_sys_kexec_file_load+0x28d/0x530 [] do_syscall_64+0x3b/0x90 [] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat.
The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2022-49546 since 02/26/2025. The exploitability is told to be difficult. Technical details are known, but no exploit is available.
The vulnerability scanner Nessus provides a plugin with the ID 234545 (SUSE SLES12 Security Update : kernel (SUSE-SU-2025:1293-1)), which helps to determine the existence of the flaw in a target environment.
Upgrading to version 5.15.46, 5.17.14 or 5.18.3 eliminates this vulnerability. Applying the patch 8765a423a87d74ef24ea02b43b2728fe4039f248/115ee42a4c2f26ba2b4ace2668a3f004621f6833/f675e3a9189d84a9324ab45b0cb19906c2bc8fcb/b3e34a47f98974d0844444c5121aaff123004e57 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
The vulnerability is also documented in the vulnerability database at Tenable (234545). If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Product
Type
Vendor
Name
Version
- 5.15.0
- 5.15.1
- 5.15.2
- 5.15.3
- 5.15.4
- 5.15.5
- 5.15.6
- 5.15.7
- 5.15.8
- 5.15.9
- 5.15.10
- 5.15.11
- 5.15.12
- 5.15.13
- 5.15.14
- 5.15.15
- 5.15.16
- 5.15.17
- 5.15.18
- 5.15.19
- 5.15.20
- 5.15.21
- 5.15.22
- 5.15.23
- 5.15.24
- 5.15.25
- 5.15.26
- 5.15.27
- 5.15.28
- 5.15.29
- 5.15.30
- 5.15.31
- 5.15.32
- 5.15.33
- 5.15.34
- 5.15.35
- 5.15.36
- 5.15.37
- 5.15.38
- 5.15.39
- 5.15.40
- 5.15.41
- 5.15.42
- 5.15.43
- 5.15.44
- 5.15.45
- 5.17.0
- 5.17.1
- 5.17.2
- 5.17.3
- 5.17.4
- 5.17.5
- 5.17.6
- 5.17.7
- 5.17.8
- 5.17.9
- 5.17.10
- 5.17.11
- 5.17.12
- 5.17.13
- 5.18.0
- 5.18.1
- 5.18.2
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 5.1VulDB Meta Temp Score: 5.0
VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔍
VulDB Reliability: 🔍
NVD Base Score: 5.5
NVD Vector: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Reliability: 🔍
Exploiting
Class: Memory leakCWE: CWE-401 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍
Physical: Partially
Local: Yes
Remote: Partially
Availability: 🔍
Status: Not defined
EPSS Score: 🔍
EPSS Percentile: 🔍
Price Prediction: 🔍
Current Price Estimation: 🔍
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Nessus ID: 234545
Nessus Name: SUSE SLES12 Security Update : kernel (SUSE-SU-2025:1293-1)
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: Kernel 5.15.46/5.17.14/5.18.3
Patch: 8765a423a87d74ef24ea02b43b2728fe4039f248/115ee42a4c2f26ba2b4ace2668a3f004621f6833/f675e3a9189d84a9324ab45b0cb19906c2bc8fcb/b3e34a47f98974d0844444c5121aaff123004e57
Timeline
02/26/2025 🔍02/26/2025 🔍
02/26/2025 🔍
04/17/2025 🔍
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2022-49546 (🔍)
GCVE (CVE): GCVE-0-2022-49546
GCVE (VulDB): GCVE-100-297117
Entry
Created: 02/26/2025 10:24Updated: 04/17/2025 17:14
Changes: 02/26/2025 10:24 (58), 04/10/2025 15:29 (12), 04/17/2025 17:14 (2)
Complete: 🔍
Cache ID: 216::103
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
No comments yet. Languages: en.
Please log in to comment.