Integer Overflow or Wraparound Affecting kernel-debug-modules-partner package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 applicationsSnyk Learn
Learn about Integer Overflow or Wraparound vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-CENTOS9-KERNELDEBUGMODULESPARTNER-10447776
- published20 Jun 2025
- disclosed18 Jun 2025
Introduced: 18 Jun 2025
CVE-2022-49964 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 kernel-debug-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-debug-modules-partner package and not the kernel-debug-modules-partner package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level
Though acpi_find_last_cache_level() always returned signed value and the document states it will return any errors caused by lack of a PPTT table, it never returned negative values before.
Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") however changed it by returning -ENOENT if no PPTT was found. The value returned from acpi_find_last_cache_level() is then assigned to unsigned fw_level.
It will result in the number of cache leaves calculated incorrectly as a huge value which will then cause the following warning from __alloc_pages as the order would be great than MAX_ORDER because of incorrect and huge cache leaves value.
| WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Call trace: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | __kmalloc+0x240/0x338 | detect_cache_attributes+0xe0/0x56c | update_siblings_masks+0x38/0x284 | store_cpu_topology+0x78/0x84 | smp_prepare_cpus+0x48/0x134 | kernel_init_freeable+0xc4/0x14c | kernel_init+0x2c/0x1b4 | ret_from_fork+0x10/0x20
Fix the same by changing fw_level to be signed integer and return the error from init_cache_level() early in case of error.
References
- https://access.redhat.com/security/cve/CVE-2022-49964
- https://git.kernel.org/stable/c/1668c38ef2e5bb80dbee88afcecfcdc3e7abc2aa
- https://git.kernel.org/stable/c/29906311b351e5398aff2c5dc209f8b6c9d6a410
- https://git.kernel.org/stable/c/43b9af72751a98cb9c074b170fc244714aeb59d5
- https://git.kernel.org/stable/c/fcab25a6b0ace130589d810390d1ce3698b53604
- https://git.kernel.org/stable/c/a754ee1c66bd0a23e613f0bf865053b29cb90e16
- https://git.kernel.org/stable/c/e75d18cecbb3805895d8ed64da4f78575ec96043