OESA-2026-1010 (CVE-2025-38211)
Vulnerability from osv_openeuler – Published: 2026-01-09 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction
The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction.
However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:
BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091
CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: <TASK> dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30
Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30
Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30
This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.
To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, mo ---truncated---(CVE-2025-38211)
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: ensure the received length does not exceed allocated size
In xdp_linearize_page, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.(CVE-2025-38375)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid
Fixes a crash when layout is null during this call stack:
write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode
pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.(CVE-2025-68349)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"perf-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-297.0.0.200.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-297.0.0.200.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"perf-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-297.0.0.200.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-297.0.0.200.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/iwcm: Fix use-after-free of work objects after cm_id destruction\n\nThe commit 59c68ac31e15 (\u0026quot;iw_cm: free cm_id resources on the last\nderef\u0026quot;) simplified cm_id resource management by freeing cm_id once all\nreferences to the cm_id were removed. The references are removed either\nupon completion of iw_cm event handlers or when the application destroys\nthe cm_id. This commit introduced the use-after-free condition where\ncm_id_private object could still be in use by event handler works during\nthe destruction of cm_id. The commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a\nuse-after-free related to destroying CM IDs\u0026quot;) addressed this use-after-\nfree by flushing all pending works at the cm_id destruction.\n\nHowever, still another use-after-free possibility remained. It happens\nwith the work objects allocated for each cm_id_priv within\nalloc_work_entries() during cm_id creation, and subsequently freed in\ndealloc_work_entries() once all references to the cm_id are removed.\nIf the cm_id\u0026apos;s last reference is decremented in the event handler work,\nthe work object for the work itself gets removed, and causes the use-\nafter-free BUG below:\n\n BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250\n Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091\n\n CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n Workqueue: 0x0 (iw_cm_wq)\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6a/0x90\n print_report+0x174/0x554\n ? __virt_addr_valid+0x208/0x430\n ? __pwq_activate_work+0x1ff/0x250\n kasan_report+0xae/0x170\n ? __pwq_activate_work+0x1ff/0x250\n __pwq_activate_work+0x1ff/0x250\n pwq_dec_nr_in_flight+0x8c5/0xfb0\n process_one_work+0xc11/0x1460\n ? __pfx_process_one_work+0x10/0x10\n ? assign_work+0x16c/0x240\n worker_thread+0x5ef/0xfd0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x3b0/0x770\n ? __pfx_kthread+0x10/0x10\n ? rcu_is_watching+0x11/0xb0\n ? _raw_spin_unlock_irq+0x24/0x50\n ? rcu_is_watching+0x11/0xb0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 147416:\n kasan_save_stack+0x2c/0x50\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0xa6/0xb0\n alloc_work_entries+0xa9/0x260 [iw_cm]\n iw_cm_connect+0x23/0x4a0 [iw_cm]\n rdma_connect_locked+0xbfd/0x1920 [rdma_cm]\n nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]\n cma_cm_event_handler+0xae/0x320 [rdma_cm]\n cma_work_handler+0x106/0x1b0 [rdma_cm]\n process_one_work+0x84f/0x1460\n worker_thread+0x5ef/0xfd0\n kthread+0x3b0/0x770\n ret_from_fork+0x30/0x70\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 147091:\n kasan_save_stack+0x2c/0x50\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kfree+0x13a/0x4b0\n dealloc_work_entries+0x125/0x1f0 [iw_cm]\n iwcm_deref_id+0x6f/0xa0 [iw_cm]\n cm_work_handler+0x136/0x1ba0 [iw_cm]\n process_one_work+0x84f/0x1460\n worker_thread+0x5ef/0xfd0\n kthread+0x3b0/0x770\n ret_from_fork+0x30/0x70\n ret_from_fork_asm+0x1a/0x30\n\n Last potentially related work creation:\n kasan_save_stack+0x2c/0x50\n kasan_record_aux_stack+0xa3/0xb0\n __queue_work+0x2ff/0x1390\n queue_work_on+0x67/0xc0\n cm_event_handler+0x46a/0x820 [iw_cm]\n siw_cm_upcall+0x330/0x650 [siw]\n siw_cm_work_handler+0x6b9/0x2b20 [siw]\n process_one_work+0x84f/0x1460\n worker_thread+0x5ef/0xfd0\n kthread+0x3b0/0x770\n ret_from_fork+0x30/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThis BUG is reproducible by repeating the blktests test case nvme/061\nfor the rdma transport and the siw driver.\n\nTo avoid the use-after-free of cm_id_private work objects, ensure that\nthe last reference to the cm_id is decremented not in the event handler\nworks, but in the cm_id destruction context. For that purpose, mo\n---truncated---(CVE-2025-38211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: ensure the received length does not exceed allocated size\n\nIn xdp_linearize_page, when reading the following buffers from the ring,\nwe forget to check the received length with the true allocate size. This\ncan lead to an out-of-bound read. This commit adds that missing check.(CVE-2025-38375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid\n\nFixes a crash when layout is null during this call stack:\n\nwrite_inode\n -\u0026gt; nfs4_write_inode\n -\u0026gt; pnfs_layoutcommit_inode\n\npnfs_set_layoutcommit relies on the lseg refcount to keep the layout\naround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt\nto reference a null layout.(CVE-2025-68349)",
"id": "OESA-2026-1010",
"modified": "2026-08-06T11:10:03Z",
"published": "2026-01-09T11:10:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38375"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68349"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-38211",
"CVE-2025-38375",
"CVE-2025-68349"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.