Memory Leak Affecting kernel-uek64k-modules-wireless package, versions <0:6.12.0-103.40.4.1.el10uek


Severity

Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.01% (2nd 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-ORACLE10-KERNELUEK64KMODULESWIRELESS-12568091
  • published10 Sept 2025
  • disclosed25 Jul 2025

Introduced: 25 Jul 2025

CVE-2025-38419  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

Upgrade Oracle:10 kernel-uek64k-modules-wireless to version 0:6.12.0-103.40.4.1.el10uek or higher.
This issue was patched in ELSA-2025-20551.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek64k-modules-wireless package and not the kernel-uek64k-modules-wireless package as distributed by Oracle. See How to fix? for Oracle:10 relevant fixed versions and status.

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

remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()

When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur.

Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label.

unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20

CVSS Base Scores

version 3.1