Memory Leak Affecting ocfs2-kmp-default package, versions <5.14.21-150400.24.184.1
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 applications- Snyk IDSNYK-SLES154-OCFS2KMPDEFAULT-14042807
- published18 Nov 2025
- disclosed15 Nov 2025
Introduced: 15 Nov 2025
CVE-2022-50545 (opens in a new tab)How to fix?
Upgrade SLES:15.4 ocfs2-kmp-default to version 5.14.21-150400.24.184.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream ocfs2-kmp-default package and not the ocfs2-kmp-default package as distributed by SLES.
See How to fix? for SLES:15.4 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffff827e20ee>] phy_device_create+0x4e/0x90 [<ffffffff827e6072>] get_phy_device+0xd2/0x220 [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0 [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0 [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040] ...
The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path
// error handling path
err_out_mdio_unregister:
mdiobus_unregister(lp->mii_bus);
err_out_mdio:
mdiobus_free(lp->mii_bus); <- the reference count of the first
phy_device is 1, it is not released
and other phy_devices are released
// similarly, the remove process also has the same problem
The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path.
Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully.
References
- https://www.suse.com/security/cve/CVE-2022-50545.html
- https://bugzilla.suse.com/1251285
- https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d
- https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269
- https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44
- https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f
- https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a
- https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36
- https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071
- https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e
- https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd