GHSA-VWG7-HHF5-FF3G

Vulnerability from github – Published: 2025-04-18 15:31 – Updated: 2025-11-07 00:30

Details

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

x86/mce: use is_copy_from_user() to determine copy-from-user context

Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.

1. What am I trying to do:

This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.

- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space

2. What is the expected outcome and why

For copyin case:

Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.

For instr case:

If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.

3. What actually happens and why

For copyin case: kernel panic since v5.17

Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().

For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race

When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.

Background: why UNcorrected errors tied to CMCI in Intel platform [1]

Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.

Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to

CMCI. Just to add to the confusion, Linux does take an action (in

uc_decode_notifier()) to try to offline the page despite the UCNA signature name.

Background: why #CMCI and #MCE race when poison is consuming in

Intel platform [1]

Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.

Thus:

1) Core is clever and thinks address A is needed soon, issues a speculative read.

2) Core finds it is going to use address A soon after sending the read request

3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.

Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).

Why user process is killed for instr case

Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-39989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-18T07:15:44Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \"mm/hwpoison: Fix regressions in memory failure handling\",\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n    - copyin case: poison found in user page while kernel copying from user space\n    - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing.  More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered.  When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible.  User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG.  It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n  and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank.  This was overkill because\nit\u0027s not an urgent problem that no core is on the verge of consuming that\nbad data.  It\u0027s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI.  Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n    Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too.  But the memory controller is\nexecuting asynchronously from the core, and can\u0027t tell the difference\nbetween a \"real\" read and a speculative read.  So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n   speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n   request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n   core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\"mm/hwpoison: fix error page recovered but reported\n\"not\n---truncated---",
  "id": "GHSA-vwg7-hhf5-ff3g",
  "modified": "2025-11-07T00:30:26Z",
  "published": "2025-04-18T15:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39989"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWM6-3CGQ-CW2W

Vulnerability from github – Published: 2022-10-21 12:00 – Updated: 2022-10-24 19:00

Details

A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability.

Severity

3.3 (Low)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-3629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-404"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-21T06:15:00Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability.",
  "id": "GHSA-vwm6-3cgq-cw2w",
  "modified": "2022-10-24T19:00:17Z",
  "published": "2022-10-21T12:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3629"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.211930"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.211930"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWQH-89QP-XCPW

Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-08-13 18:31

Details

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

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

Debounce clock reference leak: The debounce clock (bank->db_clk) is obtained using of_clk_get() which increments the clock's reference count, but clk_put() is never called. Register a devm action to cleanly release it on unbind. Note that of_clk_get(..., 1) remains necessary over devm_clk_get() because the DT binding does not define clock-names, precluding name-based lookup.
Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().
IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-64241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-24T16:16:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: rockchip: teardown bugs and resource leaks\n\nAddress several teardown issues and resource leaks in the driver\u0027s remove\npath and error handling:\n\n1. Debounce clock reference leak: The debounce clock (bank-\u003edb_clk) is\n   obtained using of_clk_get() which increments the clock\u0027s reference\n   count, but clk_put() is never called. Register a devm action to\n   cleanly release it on unbind. Note that of_clk_get(..., 1) remains\n   necessary over devm_clk_get() because the DT binding does not define\n   clock-names, precluding name-based lookup.\n\n2. Unregistered chained IRQ handler: The chained IRQ handler is not\n   disconnected in remove(). If a stray interrupt fires after the driver\n   is removed, the kernel attempts to execute a stale handler, leading\n   to a panic. Fix this by clearing the handler in remove().\n\n3. IRQ domain leak: The linear IRQ domain and its generic chips are\n   allocated manually during probe but never removed. Remove the IRQ\n   domain during driver teardown to free the associated generic chips\n   and mappings.\n\n[Bartosz: don\u0027t emit an error message on devres allocation failure]",
  "id": "GHSA-vwqh-89qp-xcpw",
  "modified": "2026-08-13T18:31:10Z",
  "published": "2026-07-24T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64241"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6be81e77e1748665d7ddab9128ff1d35eb75b87d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7f945f7f10f442270518dfd768d230227c495fcf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9500077678230e36d22bf16d2b9539c13e59a801"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cdc603ce3118232712ba443dd8b414d8f25ca467"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWV5-298P-PW28

Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-06-30 03:36

Details

A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-3104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-772"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T14:16:36Z",
    "severity": "HIGH"
  },
  "details": "A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain.\nThis issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.\nBIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.",
  "id": "GHSA-vwv5-298p-pw28",
  "modified": "2026-06-30T03:36:00Z",
  "published": "2026-03-25T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3104"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6935"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-3104"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2451310"
    },
    {
      "type": "WEB",
      "url": "https://downloads.isc.org/isc/bind9/9.20.21"
    },
    {
      "type": "WEB",
      "url": "https://downloads.isc.org/isc/bind9/9.21.20"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2026-3104"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-3104.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VX69-74F2-J536

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-08-16 00:00

Details

Several memory leaks were found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU in versions up to and including 6.0. They exist in contrib/vhost-user-gpu/vhost-user-gpu.c and contrib/vhost-user-gpu/virgl.c due to improper release of memory (i.e., free) after effective lifetime.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-3544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Several memory leaks were found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU in versions up to and including 6.0. They exist in contrib/vhost-user-gpu/vhost-user-gpu.c and contrib/vhost-user-gpu/virgl.c due to improper release of memory (i.e., free) after effective lifetime.",
  "id": "GHSA-vx69-74f2-j536",
  "modified": "2022-08-16T00:00:42Z",
  "published": "2022-05-24T19:03:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3544"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1958935"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-27"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210720-0008"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4980"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/05/31/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXF7-8458-RQ8X

Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-07 21:31

Details

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

net: mhi: Fix memory leak in mhi_net_dellink()

MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak.

This patch calls free_netdev() to fix it since netdev_priv is used after unregister.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-49817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mhi: Fix memory leak in mhi_net_dellink()\n\nMHI driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch calls free_netdev() to fix it since netdev_priv\nis used after unregister.",
  "id": "GHSA-vxf7-8458-rq8x",
  "modified": "2025-11-07T21:31:19Z",
  "published": "2025-05-01T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49817"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25a270343b0f16e1f6e65f541a15975a35e238ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88da008e5e2f9753726ea5a51ef2eb144e9de927"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7c125bd79f50ec6094761090be81d02726ec6f4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXJ7-P6GH-99VG

Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-14 21:32

Details

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

drm/i915: Fix a memory leak with reused mmap_offset

drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked.

Call drm_vma_node_allow_once() instead to prevent that memory leak.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-53002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T17:15:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix a memory leak with reused mmap_offset\n\ndrm_vma_node_allow() and drm_vma_node_revoke() should be called in\nbalanced pairs. We call drm_vma_node_allow() once per-file everytime a\nuser calls mmap_offset, but only call drm_vma_node_revoke once per-file\non each mmap_offset. As the mmap_offset is reused by the client, the\nper-file vm_count may remain non-zero and the rbtree leaked.\n\nCall drm_vma_node_allow_once() instead to prevent that memory leak.",
  "id": "GHSA-vxj7-p6gh-99vg",
  "modified": "2025-04-14T21:32:23Z",
  "published": "2025-03-27T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53002"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0220e4fe178c3390eb0291cdb34912d66972db8a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W24W-WP77-QFFM

Vulnerability from github – Published: 2023-07-05 21:34 – Updated: 2023-07-05 21:34

Summary

CometBFT may duplicate transactions in the mempool's data structures

Details

Impact

The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list.

Unfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node.

These are the steps to cause the above duplication problem. Everything should happen within one height, that is no FinalizeBlock or BeginBlock ABCI calls should happen while these steps are reproduced:

send transaction tx1 to the target full node via RPC
send N more different transactions to the target full node, where N should be higher than the node's configured value for cache_size in config.toml
send transaction tx1 again to the target full node

One of the copies of tx1 is now stuck in the mempool's data structures. Effectively causing a memory leak, and having that node gossiping that transaction to its peers forever.

The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node.

This problem is present in releases: v0.37.0, and v0.37.1, as well as in v0.34.28, and all previous releases of the CometBFT repo. It will be fixed in releases v0.34.29 and v0.37.2.

Patches

The PR containing the fix is here.

Workarounds

Increasing the value of cache_size in config.toml makes it very difficult to effectively attack a full node.
Not exposing the transaction submission RPC's would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.

References

PR that introduced the map to track transactions in the mempool.
PR containing the fix.

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cometbft/cometbft"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.34.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cometbft/cometbft"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.37.0"
            },
            {
              "fixed": "0.37.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-34451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-05T21:34:45Z",
    "nvd_published_at": "2023-07-03T17:15:09Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe mempool maintains two data structures to keep track of outstanding transactions: a list and a map.\nThese two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. \n\nUnfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction.\nBecause the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list.\nThis happens  even if the duplicated transaction is later committed in a block.\nThe only way to remove the transaction is by restarting the node.\n\nThese are the steps to cause the above duplication problem. Everything should happen within one height, that is no `FinalizeBlock` or `BeginBlock` ABCI calls should happen while these steps are reproduced:\n\n1. send transaction tx1 to the target full node via RPC\n2. send N more different transactions to the target full node, where N should be higher than the node\u0027s configured value for `cache_size` in `config.toml`\n3. send transaction tx1 again to the target full node\n\nOne of the copies of tx1 is now _stuck_ in the mempool\u0027s data structures. Effectively causing a memory leak, and having that node gossiping that transaction to its peers forever.\n\nThe above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node.\n\nThis problem is present in releases: `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo. It will be fixed in releases `v0.34.29` and `v0.37.2`.\n\n### Patches\n\nThe PR containing the fix is [here](https://github.com/cometbft/cometbft/pull/890).\n\n\n### Workarounds\n\n* Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node.\n* Not exposing the transaction submission RPC\u0027s would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.\n\n### References\n\n* [PR](https://github.com/tendermint/tendermint/pull/2778) that introduced the map to track transactions in the mempool.\n* [PR](https://github.com/cometbft/cometbft/pull/890) containing the fix.\n",
  "id": "GHSA-w24w-wp77-qffm",
  "modified": "2023-07-05T21:34:45Z",
  "published": "2023-07-05T21:34:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cometbft/cometbft/pull/890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tendermint/tendermint/pull/2778"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cometbft/cometbft"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CometBFT may duplicate transactions in the mempool\u0027s data structures"
}

GHSA-W279-MJ9J-W893

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-19 15:33

Details

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-46065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:27Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.",
  "id": "GHSA-w279-mj9j-w893",
  "modified": "2026-06-19T15:33:13Z",
  "published": "2026-05-27T15:33:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25c2b77bc463f29ee71a54b883548baf9386a0db"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a40f8bc9bb713329f1c35ffc199ee961a7135b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b53d3a52e8e5403a4f4fb57ac6cad3fd2cb1066"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4aab89603b637a2e441b38808c4f6fe7d1184df6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4fda0d6b45faad44926dd3e4f55f118d899b2e27"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ded47ad003f09a94b6a710b5c47f4aa5ceb7429"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0aafb421dd15e935d81543152617f2742cefa70"
    }
  ],
  "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-W299-FQ8V-QVG7

Vulnerability from github – Published: 2026-01-27 12:31 – Updated: 2026-01-27 12:31

Details

Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-24828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T10:15:49Z",
    "severity": "HIGH"
  },
  "details": "Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4.",
  "id": "GHSA-w299-fq8v-qvg7",
  "modified": "2026-01-27T12:31:18Z",
  "published": "2026-01-27T12:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24828"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Is-Daouda/is-Engine/pull/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-401

Missing Release of Memory after Effective Lifetime

GHSA-VWG7-HHF5-FF3G

1. What am I trying to do:

2. What is the expected outcome and why

3. What actually happens and why

Background: why UNcorrected errors tied to CMCI in Intel platform [1]

CMCI. Just to add to the confusion, Linux does take an action (in

Background: why #CMCI and #MCE race when poison is consuming in

Why user process is killed for instr case

GHSA-VWM6-3CGQ-CW2W

GHSA-VWQH-89QP-XCPW

GHSA-VWV5-298P-PW28

GHSA-VX69-74F2-J536

GHSA-VXF7-8458-RQ8X

GHSA-VXJ7-P6GH-99VG

GHSA-W24W-WP77-QFFM

Impact

Patches

Workarounds

References

GHSA-W279-MJ9J-W893

GHSA-W299-FQ8V-QVG7

Mitigation MIT-41

Mitigation

Mitigation