Common Weakness Enumeration

CWE-416

Allowed

Use After Free

Abstraction: Variant · Status: Stable

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

9821 vulnerabilities reference this CWE, most recent first.

GHSA-M3MC-3JRW-X2PJ

Vulnerability from github – Published: 2022-09-19 00:00 – Updated: 2022-09-22 00:00
VLAI
Details

Use After Free in GitHub repository vim/vim prior to 9.0.0490.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-18T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use After Free in GitHub repository vim/vim prior to 9.0.0490.",
  "id": "GHSA-m3mc-3jrw-x2pj",
  "modified": "2022-09-22T00:00:30Z",
  "published": "2022-09-19T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3235"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vim/vim/commit/1c3dd8ddcba63c1af5112e567215b3cec2de11d0"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/96d5f7a0-a834-4571-b73b-0fe523b941af"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4QI7AETXBHPC7SGA77Q7O5IEGULWYET7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GTBVD4J2SKVSWK4VBN5JP5OEVK6GDS3N"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LSSEWQLK55MCNT4Z2IIJEJYEI5HLCODI"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3QQ-5J3G-RQ9Q

Vulnerability from github – Published: 2024-05-07 09:30 – Updated: 2024-05-07 09:30
VLAI
Details

in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution in TCB through use after free.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-07T07:15:50Z",
    "severity": "MODERATE"
  },
  "details": "in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution in TCB through use after free.",
  "id": "GHSA-m3qq-5j3g-rq9q",
  "modified": "2024-05-07T09:30:32Z",
  "published": "2024-05-07T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3759"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-05.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3R3-6XWH-QJG6

Vulnerability from github – Published: 2025-08-13 00:30 – Updated: 2025-08-13 00:30
VLAI
Details

Adobe Framemaker versions 2020.8, 2022.6 and earlier are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T23:15:28Z",
    "severity": "HIGH"
  },
  "details": "Adobe Framemaker versions 2020.8, 2022.6 and earlier are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
  "id": "GHSA-m3r3-6xwh-qjg6",
  "modified": "2025-08-13T00:30:56Z",
  "published": "2025-08-13T00:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54229"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/framemaker/apsb25-83.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3R4-HPJV-PH84

Vulnerability from github – Published: 2025-03-04 18:33 – Updated: 2025-03-04 18:33
VLAI
Details

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

powerpc/pseries: Fix use after free in remove_phb_dynamic()

In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge.

If there are no outstanding references when we call device_unregister() then phb will be freed out from under us.

This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash:

PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168

To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:56Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries: Fix use after free in remove_phb_dynamic()\n\nIn remove_phb_dynamic() we use \u0026phb-\u003eio_resource, after we\u0027ve called\ndevice_unregister(\u0026host_bridge-\u003edev). But the unregister may have freed\nphb, because pcibios_free_controller_deferred() is the release function\nfor the host_bridge.\n\nIf there are no outstanding references when we call device_unregister()\nthen phb will be freed out from under us.\n\nThis has gone mainly unnoticed, but with slub_debug and page_poison\nenabled it can lead to a crash:\n\n  PID: 7574   TASK: c0000000d492cb80  CPU: 13  COMMAND: \"drmgr\"\n   #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc\n   #1 [c0000000e4f075d0] oops_end at c000000000029608\n   #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4\n   #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8\n   #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30\n   Data SLB Access [380] exception frame:\n   R0:  c000000000167250    R1:  c0000000e4f07a00    R2:  c000000002a46100\n   R3:  c000000002b39ce8    R4:  00000000000000c0    R5:  00000000000000a9\n   R6:  3894674d000000c0    R7:  0000000000000000    R8:  00000000000000ff\n   R9:  0000000000000100    R10: 6b6b6b6b6b6b6b6b    R11: 0000000000008000\n   R12: c00000000023da80    R13: c0000009ffd38b00    R14: 0000000000000000\n   R15: 000000011c87f0f0    R16: 0000000000000006    R17: 0000000000000003\n   R18: 0000000000000002    R19: 0000000000000004    R20: 0000000000000005\n   R21: 000000011c87ede8    R22: 000000011c87c5a8    R23: 000000011c87d3a0\n   R24: 0000000000000000    R25: 0000000000000001    R26: c0000000e4f07cc8\n   R27: c00000004d1cc400    R28: c0080000031d00e8    R29: c00000004d23d800\n   R30: c00000004d1d2400    R31: c00000004d1d2540\n   NIP: c000000000167258    MSR: 8000000000009033    OR3: c000000000e9f474\n   CTR: 0000000000000000    LR:  c000000000167250    XER: 0000000020040003\n   CCR: 0000000024088420    MQ:  0000000000000000    DAR: 6b6b6b6b6b6b6ba3\n   DSISR: c0000000e4f07920     Syscall Result: fffffffffffffff2\n   [NIP  : release_resource+56]\n   [LR   : release_resource+48]\n   #5 [c0000000e4f07a00] release_resource at c000000000167258  (unreliable)\n   #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648\n   #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]\n   #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]\n   #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c\n  #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504\n  #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868\n  #12 [c0000000e4f07c70] new_sync_write at c00000000054339c\n  #13 [c0000000e4f07d10] vfs_write at c000000000546624\n  #14 [c0000000e4f07d60] ksys_write at c0000000005469f4\n  #15 [c0000000e4f07db0] system_call_exception at c000000000030840\n  #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168\n\nTo avoid it, we can take a reference to the host_bridge-\u003edev until we\u0027re\ndone using phb. Then when we drop the reference the phb will be freed.",
  "id": "GHSA-m3r4-hpjv-ph84",
  "modified": "2025-03-04T18:33:26Z",
  "published": "2025-03-04T18:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49196"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33d39efb61a84e055ca2386157d39ebbdf6b7d31"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/403f9e0bc5535a0a5184d1352fa3a70e6ffacb6f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/895ca4ae1f72e0a0160ab162723e59c9f265ec93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe2640bd7a62f1f7c3f55fbda31084085075bc30"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3VG-G7CW-RHF8

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader 9.0.1.5096. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of Text annotations. By manipulating a document's elements, an attacker can cause a pointer to be reused after it has been freed. An attacker can leverage this vulnerability to execute code under the context of the current process. Was ZDI-CAN-6220.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-14304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-31T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader 9.0.1.5096. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of Text annotations. By manipulating a document\u0027s elements, an attacker can cause a pointer to be reused after it has been freed. An attacker can leverage this vulnerability to execute code under the context of the current process. Was ZDI-CAN-6220.",
  "id": "GHSA-m3vg-g7cw-rhf8",
  "modified": "2022-05-13T01:34:34Z",
  "published": "2022-05-13T01:34:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14304"
    },
    {
      "type": "WEB",
      "url": "https://www.foxitsoftware.com/support/security-bulletins.php"
    },
    {
      "type": "WEB",
      "url": "https://zerodayinitiative.com/advisories/ZDI-18-764"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3VJ-8MH5-6QW4

Vulnerability from github – Published: 2022-05-17 02:21 – Updated: 2022-05-17 02:21
VLAI
Details

Use-after-free vulnerability in Adobe Reader and Acrobat before 11.0.18, Acrobat and Acrobat Reader DC Classic before 15.006.30243, and Acrobat and Acrobat Reader DC Continuous before 15.020.20039 on Windows and OS X allows attackers to execute arbitrary code via unspecified vectors, a different vulnerability than CVE-2016-1089, CVE-2016-1091, CVE-2016-6944, CVE-2016-6945, CVE-2016-6946, CVE-2016-6949, CVE-2016-6952, CVE-2016-6953, CVE-2016-6961, CVE-2016-6963, CVE-2016-6964, CVE-2016-6965, CVE-2016-6967, CVE-2016-6968, CVE-2016-6969, CVE-2016-6971, CVE-2016-6979, CVE-2016-6988, and CVE-2016-6993.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-6962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-10-13T19:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "Use-after-free vulnerability in Adobe Reader and Acrobat before 11.0.18, Acrobat and Acrobat Reader DC Classic before 15.006.30243, and Acrobat and Acrobat Reader DC Continuous before 15.020.20039 on Windows and OS X allows attackers to execute arbitrary code via unspecified vectors, a different vulnerability than CVE-2016-1089, CVE-2016-1091, CVE-2016-6944, CVE-2016-6945, CVE-2016-6946, CVE-2016-6949, CVE-2016-6952, CVE-2016-6953, CVE-2016-6961, CVE-2016-6963, CVE-2016-6964, CVE-2016-6965, CVE-2016-6967, CVE-2016-6968, CVE-2016-6969, CVE-2016-6971, CVE-2016-6979, CVE-2016-6988, and CVE-2016-6993.",
  "id": "GHSA-m3vj-8mh5-6qw4",
  "modified": "2022-05-17T02:21:30Z",
  "published": "2022-05-17T02:21:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6962"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb16-33.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/93491"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1036986"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3VM-45HM-666Q

Vulnerability from github – Published: 2025-02-27 18:31 – Updated: 2025-02-27 18:31
VLAI
Details

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

bpf: Fix UAF due to race between btf_try_get_module and load_module

While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel.

Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF.

However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE.

This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future.

There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function).

An illustration of the race:

CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free

We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug.

A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO).

Lastly, a couple of comments:

  1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely.

  2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:00Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix UAF due to race between btf_try_get_module and load_module\n\nWhile working on code to populate kfunc BTF ID sets for module BTF from\nits initcall, I noticed that by the time the initcall is invoked, the\nmodule BTF can already be seen by userspace (and the BPF verifier). The\nexisting btf_try_get_module calls try_module_get which only fails if\nmod-\u003estate == MODULE_STATE_GOING, i.e. it can increment module reference\nwhen module initcall is happening in parallel.\n\nCurrently, BTF parsing happens from MODULE_STATE_COMING notifier\ncallback. At this point, the module initcalls have not been invoked.\nThe notifier callback parses and prepares the module BTF, allocates an\nID, which publishes it to userspace, and then adds it to the btf_modules\nlist allowing the kernel to invoke btf_try_get_module for the BTF.\n\nHowever, at this point, the module has not been fully initialized (i.e.\nits initcalls have not finished). The code in module.c can still fail\nand free the module, without caring for other users. However, nothing\nstops btf_try_get_module from succeeding between the state transition\nfrom MODULE_STATE_COMING to MODULE_STATE_LIVE.\n\nThis leads to a use-after-free issue when BPF program loads\nsuccessfully in the state transition, load_module\u0027s do_init_module call\nfails and frees the module, and BPF program fd on close calls module_put\nfor the freed module. Future patch has test case to verify we don\u0027t\nregress in this area in future.\n\nThere are multiple points after prepare_coming_module (in load_module)\nwhere failure can occur and module loading can return error. We\nillustrate and test for the race using the last point where it can\npractically occur (in module __init function).\n\nAn illustration of the race:\n\nCPU 0                           CPU 1\n\t\t\t  load_module\n\t\t\t    notifier_call(MODULE_STATE_COMING)\n\t\t\t      btf_parse_module\n\t\t\t      btf_alloc_id\t// Published to userspace\n\t\t\t      list_add(\u0026btf_mod-\u003elist, btf_modules)\n\t\t\t    mod-\u003einit(...)\n...\t\t\t\t^\nbpf_check\t\t        |\ncheck_pseudo_btf_id             |\n  btf_try_get_module            |\n    returns true                |  ...\n...                             |  module __init in progress\nreturn prog_fd                  |  ...\n...                             V\n\t\t\t    if (ret \u003c 0)\n\t\t\t      free_module(mod)\n\t\t\t    ...\nclose(prog_fd)\n ...\n bpf_prog_free_deferred\n  module_put(used_btf.mod) // use-after-free\n\nWe fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier\ncallback when MODULE_STATE_LIVE state is reached for the module, so that\nwe return NULL from btf_try_get_module for modules that are not fully\nformed. Since try_module_get already checks that module is not in\nMODULE_STATE_GOING state, and that is the only transition a live module\ncan make before being removed from btf_modules list, this is enough to\nclose the race and prevent the bug.\n\nA later selftest patch crafts the race condition artifically to verify\nthat it has been fixed, and that verifier fails to load program (with\nENXIO).\n\nLastly, a couple of comments:\n\n 1. Even if this race didn\u0027t exist, it seems more appropriate to only\n    access resources (ksyms and kfuncs) of a fully formed module which\n    has been initialized completely.\n\n 2. This patch was born out of need for synchronization against module\n    initcall for the next patch, so it is needed for correctness even\n    without the aforementioned race condition. The BTF resources\n    initialized by module initcall are set up once and then only looked\n    up, so just waiting until the initcall has finished ensures correct\n    behavior.",
  "id": "GHSA-m3vm-45hm-666q",
  "modified": "2025-02-27T18:31:08Z",
  "published": "2025-02-27T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49236"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0481baa2318cb1ab13277715da6cdbb657807b3f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/18688de203b47e5d8d9d0953385bf30b5949324f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51b82141fffa454abf937a8ff0b8af89e4fd0c8f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7fccf264b1a785525b366a5b7f8113c756187ad"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3W6-RJ5M-CFPP

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-12-17 18:31
VLAI
Details

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

net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done

Syzbot reported a slab-use-after-free with the following call trace:

================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25

Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231

Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394

Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231

After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.

I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1

The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.

tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base;

simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)

Fix this by holding net reference count before encrypt.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T10:15:37Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n  Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n  Call Trace:\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n   crypto_request_complete include/crypto/algapi.h:266\n   aead_request_complete include/crypto/internal/aead.h:85\n   cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n   crypto_request_complete include/crypto/algapi.h:266\n   cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n  Allocated by task 8355:\n   kzalloc_noprof include/linux/slab.h:778\n   tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n   tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n   ops_init+0xb9/0x650 net/core/net_namespace.c:139\n   setup_net+0x435/0xb40 net/core/net_namespace.c:343\n   copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n   create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n   unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n   ksys_unshare+0x419/0x970 kernel/fork.c:3323\n   __do_sys_unshare kernel/fork.c:3394\n\n  Freed by task 63:\n   kfree+0x12a/0x3b0 mm/slub.c:4557\n   tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n   tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n   ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n   cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n  ip netns add ns1\n  ip link add veth1 type veth peer name veth2\n  ip link set veth1 netns ns1\n  ip netns exec ns1 tipc bearer enable media eth dev veth1\n  ip netns exec ns1 tipc node set key this_is_a_master_key master\n  ip netns exec ns1 tipc bearer disable media eth dev veth1\n  ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n  tipc_disc_timeout\n    tipc_bearer_xmit_skb\n      tipc_crypto_xmit\n        tipc_aead_encrypt\n          crypto_aead_encrypt\n            // encrypt()\n            simd_aead_encrypt\n              // crypto_simd_usable() is false\n              child = \u0026ctx-\u003ecryptd_tfm-\u003ebase;\n\n  simd_aead_encrypt\n    crypto_aead_encrypt\n      // encrypt()\n      cryptd_aead_encrypt_enqueue\n        cryptd_aead_enqueue\n          cryptd_enqueue_request\n            // trigger cryptd_queue_worker\n            queue_work_on(smp_processor_id(), cryptd_wq, \u0026cpu_queue-\u003ework)\n\nFix this by holding net reference count before encrypt.",
  "id": "GHSA-m3w6-rj5m-cfpp",
  "modified": "2025-12-17T18:31:31Z",
  "published": "2025-06-18T12:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38052"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4a0fddc2c0d5c28aec8c262ad4603be0bef1938c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/689a205cd968a1572ab561b0c4c2d50a10e9d3b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b19fc1d0be3c3397e5968fe2627f22e7f84673b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b8fcae6d2e93c54cacb8f579a77d827c1c643eb5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d42ed4de6aba232d946d20653a70f79158a6535b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e279024617134c94fd3e37470156534d5f2b3472"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5c2c4eaaa5a8e7e0685ec031d480e588e263e59"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3WW-86W6-HQWQ

Vulnerability from github – Published: 2022-08-13 00:00 – Updated: 2022-08-16 00:00
VLAI
Details

Use after free in Input in Google Chrome on Chrome OS prior to 104.0.5112.79 allowed a remote attacker who convinced a user to enage in specific user interactions to potentially exploit heap corruption via specific UI interactions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-2613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-12T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use after free in Input in Google Chrome on Chrome OS prior to 104.0.5112.79 allowed a remote attacker who convinced a user to enage in specific user interactions to potentially exploit heap corruption via specific UI interactions.",
  "id": "GHSA-m3ww-86w6-hqwq",
  "modified": "2022-08-16T00:00:23Z",
  "published": "2022-08-13T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2613"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1325256"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M42G-4P87-QCRH

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2023-03-29 18:30
VLAI
Details

Live555 before 2019.08.16 has a Use-After-Free because GenericMediaServer::createNewClientSessionWithId can generate the same client session ID in succession, which is mishandled by the MPEG1or2 and Matroska file demultiplexors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-20T00:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Live555 before 2019.08.16 has a Use-After-Free because GenericMediaServer::createNewClientSessionWithId can generate the same client session ID in succession, which is mishandled by the MPEG1or2 and Matroska file demultiplexors.",
  "id": "GHSA-m42g-4p87-qcrh",
  "modified": "2023-03-29T18:30:29Z",
  "published": "2022-05-24T16:53:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15232"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202005-06"
    },
    {
      "type": "WEB",
      "url": "http://www.live555.com/liveMedia/public/changelog.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Language Selection

Choose a language that provides automatic memory management.

Mitigation
Implementation

Strategy: Attack Surface Reduction

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

No CAPEC attack patterns related to this CWE.