Vulnerability-Lookup

GHSA-5337-PR68-XWQF

Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 18:30

Details

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

net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create

The memory pointed to by the fs->any pointer is not freed in the error path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_fs_tt_redirect_any_destroy().

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-53371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-18T14:15:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create\n\nThe memory pointed to by the fs-\u003eany pointer is not freed in the error\npath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.\nFix by freeing the memory in the error path, thereby making the error path\nidentical to mlx5e_fs_tt_redirect_any_destroy().",
  "id": "GHSA-5337-pr68-xwqf",
  "modified": "2025-12-12T18:30:28Z",
  "published": "2025-09-18T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53371"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3250affdc658557a41df9c5fb567723e421f8bf2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/75df2fe6d160e16be880aacacd521b135d7177c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8a75a6f169c3df3a94802314aa61282772ac75b8"
    }
  ],
  "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-536V-Q9W2-W76R

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-08-13 15:34

Details

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

mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page

When check_stable_address_space() fails after the PMD spinlock has been acquired via pmd_lock(), the code jumps directly to the abort label, bypassing the spin_unlock() call in unlock_abort. This causes the PMD spinlock to be permanently held, leading to a deadlock.

Change the goto target from abort to unlock_abort to ensure the spinlock is always released on this error path.

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-64129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:54Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page\n\nWhen check_stable_address_space() fails after the PMD spinlock has\nbeen acquired via pmd_lock(), the code jumps directly to the abort\nlabel, bypassing the spin_unlock() call in unlock_abort. This causes\nthe PMD spinlock to be permanently held, leading to a deadlock.\n\nChange the goto target from abort to unlock_abort to ensure the\nspinlock is always released on this error path.",
  "id": "GHSA-536v-q9w2-w76r",
  "modified": "2026-08-13T15:34:13Z",
  "published": "2026-07-19T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64129"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/63451de16e0a08be40f9ab5e7c5c8f5c79676fb1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c715f7ccf7a294c058667b678a4ba50fad933c62"
    }
  ],
  "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-53CC-XH3P-4X9V

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 15:30

Details

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

net: macb: Shuffle the tx ring before enabling tx

Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver.

According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register.

In the current implementation, the code merely resets queue->tx_head and queue->tx_tail to '0'. This approach presents several issues:

Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released.
Concurrent write access to queue->tx_head and queue->tx_tail may occur from macb_tx_poll() or macb_start_xmit() when these values are reset to '0'.
The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail', macb_tx_poll() incorrectly assumes there are no packets to handle because queue->tx_head == queue->tx_tail. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem.

To resolve this issue, shuffle the tx ring and tx skb array so that the first unsent packet is positioned at the start of the tx ring. Additionally, ensure that updates to queue->tx_head and queue->tx_tail are properly protected with the appropriate lock.

[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm

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-43371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T15:16:48Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macb: Shuffle the tx ring before enabling tx\n\nQuanyang observed that when using an NFS rootfs on an AMD ZynqMp board,\nthe rootfs may take an extended time to recover after a suspend.\nUpon investigation, it was determined that the issue originates from a\nproblem in the macb driver.\n\nAccording to the Zynq UltraScale TRM [1], when transmit is disabled,\nthe transmit buffer queue pointer resets to point to the address\nspecified by the transmit buffer queue base address register.\n\nIn the current implementation, the code merely resets `queue-\u003etx_head`\nand `queue-\u003etx_tail` to \u00270\u0027. This approach presents several issues:\n\n- Packets already queued in the tx ring are silently lost,\n  leading to memory leaks since the associated skbs cannot be released.\n\n- Concurrent write access to `queue-\u003etx_head` and `queue-\u003etx_tail` may\n  occur from `macb_tx_poll()` or `macb_start_xmit()` when these values\n  are reset to \u00270\u0027.\n\n- The transmission may become stuck on a packet that has already been sent\n  out, with its \u0027TX_USED\u0027 bit set, but has not yet been processed. However,\n  due to the manipulation of \u0027queue-\u003etx_head\u0027 and \u0027queue-\u003etx_tail\u0027,\n  `macb_tx_poll()` incorrectly assumes there are no packets to handle\n  because `queue-\u003etx_head == queue-\u003etx_tail`. This issue is only resolved\n  when a new packet is placed at this position. This is the root cause of\n  the prolonged recovery time observed for the NFS root filesystem.\n\nTo resolve this issue, shuffle the tx ring and tx skb array so that\nthe first unsent packet is positioned at the start of the tx ring.\nAdditionally, ensure that updates to `queue-\u003etx_head` and\n`queue-\u003etx_tail` are properly protected with the appropriate lock.\n\n[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm",
  "id": "GHSA-53cc-xh3p-4x9v",
  "modified": "2026-05-15T15:30:34Z",
  "published": "2026-05-08T15:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43371"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0a47c3889fcd843c72aa57fa8c4d06f5801fced4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/403182e0771b250cfde0fe7e1081d095ceaf8230"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/58f5d34f88e8f00910b692537f7b2efdb8c3705d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/881a0263d502e1a93ebc13a78254e9ad19520232"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88f974fe118cb4653f029929ecbca7cfe06132ae"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c6783bfa31a59f34fe4feb1bdbf67791ef3fb0b7"
    }
  ],
  "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-53CW-GGRV-83HG

Vulnerability from github – Published: 2026-08-28 03:31 – Updated: 2026-08-28 03:31

Details

Multiple memory leaks in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to exhaust all available memory on the device within minutes.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-38819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T02:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Multiple memory leaks in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to exhaust all available memory on the device within minutes.",
  "id": "GHSA-53cw-ggrv-83hg",
  "modified": "2026-08-28T03:31:23Z",
  "published": "2026-08-28T03:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38819"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openNDS/openNDS/commit/b2801d9f14af44a23be7e9a1c378623bc5947c4c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openNDS/openNDS/commit/f2332e68c6d34f8403db346e380fff3817020d5c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-53HJ-G53Q-MPCC

Vulnerability from github – Published: 2025-03-07 21:31 – Updated: 2025-03-07 21:31

Details

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

nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred

Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well.

Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them.

So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak.

Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.

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-49729"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:48Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred\n\nSimilar to the handling of play_deferred in commit 19cfe912c37b\n(\"Bluetooth: btusb: Fix memory leak in play_deferred\"), we thought\na patch might be needed here as well.\n\nCurrently usb_submit_urb is called directly to submit deferred tx\nurbs after unanchor them.\n\nSo the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb\nand cause memory leak.\n\nPut those urbs in tx_anchor to avoid the leak, and also fix the error\nhandling.",
  "id": "GHSA-53hj-g53q-mpcc",
  "modified": "2025-03-07T21:31:04Z",
  "published": "2025-03-07T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49729"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c"
    }
  ],
  "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-53QV-XVFG-RJR9

Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-12-23 21:30

Details

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

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-38419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-25T14:15:33Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()\n\nWhen rproc-\u003estate = RPROC_DETACHED and rproc_attach() is used\nto attach to the remote processor, if rproc_handle_resources()\nreturns a failure, the resources allocated by imx_rproc_prepare()\nshould be released, otherwise the following memory leak will occur.\n\nSince almost the same thing is done in imx_rproc_prepare() and\nrproc_resource_cleanup(), Function rproc_resource_cleanup() is able\nto deal with empty lists so it is better to fix the \"goto\" statements\nin rproc_attach(). replace the \"unprepare_device\" goto statement with\n\"clean_up_resources\" and get rid of the \"unprepare_device\" label.\n\nunreferenced object 0xffff0000861c5d00 (size 128):\ncomm \"kworker/u12:3\", pid 59, jiffies 4294893509 (age 149.220s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............\nbacktrace:\n [\u003c00000000f949fe18\u003e] slab_post_alloc_hook+0x98/0x37c\n [\u003c00000000adbfb3e7\u003e] __kmem_cache_alloc_node+0x138/0x2e0\n [\u003c00000000521c0345\u003e] kmalloc_trace+0x40/0x158\n [\u003c000000004e330a49\u003e] rproc_mem_entry_init+0x60/0xf8\n [\u003c000000002815755e\u003e] imx_rproc_prepare+0xe0/0x180\n [\u003c0000000003f61b4e\u003e] rproc_boot+0x2ec/0x528\n [\u003c00000000e7e994ac\u003e] rproc_add+0x124/0x17c\n [\u003c0000000048594076\u003e] imx_rproc_probe+0x4ec/0x5d4\n [\u003c00000000efc298a1\u003e] platform_probe+0x68/0xd8\n [\u003c00000000110be6fe\u003e] really_probe+0x110/0x27c\n [\u003c00000000e245c0ae\u003e] __driver_probe_device+0x78/0x12c\n [\u003c00000000f61f6f5e\u003e] driver_probe_device+0x3c/0x118\n [\u003c00000000a7874938\u003e] __device_attach_driver+0xb8/0xf8\n [\u003c0000000065319e69\u003e] bus_for_each_drv+0x84/0xe4\n [\u003c00000000db3eb243\u003e] __device_attach+0xfc/0x18c\n [\u003c0000000072e4e1a4\u003e] device_initial_probe+0x14/0x20",
  "id": "GHSA-53qv-xvfg-rjr9",
  "modified": "2025-12-23T21:30:22Z",
  "published": "2025-07-25T15:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38419"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5434d9f2fd68722b514c14b417b53a8af02c4d24"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7692c9fbedd9087dc9050903f58095915458d9b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82208ce9505abb057afdece7c62a14687c52c9ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92776ca0ccfe78b9bfe847af206bad641fb11121"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9515d74c9d1ae7308a02e8bd4f894eb8137cf8df"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c56d6ef2711ee51b54f160ad0f25a381561f0287"
    },
    {
      "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:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-54JF-P4CR-5XJ6

Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30

Details

A Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).

On all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.

The memory usage can be monitored using the below command.

user@host> show task memory detail | match patroot This issue affects:

Juniper Networks Junos OS

All versions earlier than 21.2R3-S3;
21.3 versions earlier than 21.3R3-S5;
21.4 versions earlier than 21.4R3-S3;
22.1 versions earlier than 22.1R3;
22.2 versions earlier than 22.2R3.

Juniper Networks Junos OS Evolved

All versions earlier than 21.3R3-S5-EVO;
21.4 versions earlier than 21.4R3-EVO;
22.1 versions earlier than 22.1R3-EVO;
22.2 versions earlier than 22.2R3-EVO.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:A/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-2024-21613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-12T01:15:49Z",
    "severity": "MODERATE"
  },
  "details": "\nA Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).\n\nOn all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.\n\nThe memory usage can be monitored using the below command.\n\nuser@host\u003e show task memory detail | match patroot\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n  *  All versions earlier than 21.2R3-S3;\n  *  21.3 versions earlier than 21.3R3-S5;\n  *  21.4 versions earlier than 21.4R3-S3;\n  *  22.1 versions earlier than 22.1R3;\n  *  22.2 versions earlier than 22.2R3.\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n  *  All versions earlier than 21.3R3-S5-EVO;\n  *  21.4 versions earlier than 21.4R3-EVO;\n  *  22.1 versions earlier than 22.1R3-EVO;\n  *  22.2 versions earlier than 22.2R3-EVO.\n\n\n\n\n\n\n",
  "id": "GHSA-54jf-p4cr-5xj6",
  "modified": "2024-01-12T03:30:49Z",
  "published": "2024-01-12T03:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21613"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA75754"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-54P9-H82J-F925

Vulnerability from github – Published: 2026-10-05 23:40 – Updated: 2026-10-05 23:40

Summary

Multidict: Reference leak in CIMultiDict/MultiDict items-view union and subtraction

Details

Description

A reference leak in the items-view union and subtraction operators of aio-libs/multidict 6.7.0 through 6.9.0 (C extension) lets a remote client drive unbounded, unreclaimable memory growth by having each operand element leak one key-identity object and one value object. The reflected-union path (operand | d.items(), multidict_itemsview_or2_impl) and the subtraction path (d.items() - operand, multidict_itemsview_sub1_impl) parse each element into new strong references but release only the tuple wrapper, never the identity and value. Servers in the aio-libs stack build these views over attacker-supplied HTTP headers and query strings, so the operand size is under remote control. Forced garbage collection does not recover the leaked objects, so resident memory rises monotonically until the process is killed.

Root Cause

_multidict_itemsview_parse_item() returns new references: a fresh identity via md_calc_identity() and a fresh value via Py_NewRef(). The or2_impl first parse loop requests both but clears only arg:

// views.h:565 — or2_impl first parse loop
while ((st = PyIter_NextItem(iter, &arg)) > 0) {
    int tmp = _multidict_itemsview_parse_item(
        self, arg, &identity, NULL, &value);   // identity + value: new refs
    if (tmp < 0) goto fail;
    else if (tmp > 0) {
        if (_set_add(tmp_set, identity, value) < 0) goto fail;
    }
    Py_CLEAR(arg);                             // :575 clears arg ONLY
}

_set_add() builds its own tuple with PyTuple_Pack and Py_DECREFs it, so it never borrows the loop's identity/value. On the next iteration those variables are overwritten, so the previous references are lost permanently. The sub1_impl first loop (:686-696) has the identical omission.

This is an editing slip, not an ownership contract: every sibling path clears all three references per iteration, and1_impl (:304-306), and2_impl (:389-391), or1_impl (:506-508), and the second (md_next) loops of both functions (:605-607, :726-728). PR #1413 added a Py_DECREF(tpl) to the second loop of or2/sub1, fixing a different temporary-tuple leak; it never touched the first parse loop, so this leak remains on master.

views.h is byte-identical between v6.6.0 and v6.7.0, yet 6.6.4 does not leak and 6.7.0 does. The regression is behavioural, introduced by a key-identity ownership change in hashtable.h across that boundary that made md_calc_identity() return a fresh strong reference the unchanged parse loop never releases.

Reproduction Environment

Item	Value
Runtime	CPython 3.14.6
multidict	6.9.0 (PyPI binary wheel, C extension)
OS	macOS (darwin 25.6.0, arm64)

Proof of Concept

POC Source Code

poc_refcount.py — leak proof with intersection control

import sys, gc
from multidict import CIMultiDict

def probe(name, run_op):
    d = CIMultiDict(); d["seed"] = "x"
    value = object()                 # unique sentinel
    N = 100000
    operand = [("k%d" % i, value) for i in range(N)]
    gc.collect(); before = sys.getrefcount(value)
    run_op(d, operand)
    gc.collect(); after = sys.getrefcount(value)
    print(f"[{name}] leaked strong refs = {after - before}")

probe("or2  operand | items", lambda d, o: o | d.items())    # reflected union
probe("sub1 items - operand", lambda d, o: d.items() - o)    # subtraction
probe("and2 items & operand", lambda d, o: d.items() & o)    # CONTROL: clears, expect 0

poc_dispatch.py — maps which paths leak

import sys, gc
from multidict import CIMultiDict

def probe(name, fn):
    d = CIMultiDict(); d["seed"] = "x"
    v = object(); N = 50000
    operand = [("k%d" % i, v) for i in range(N)]
    gc.collect(); before = sys.getrefcount(v)
    fn(d, operand); gc.collect(); after = sys.getrefcount(v)
    print(f"{name:35s} leaked={after - before}")

probe("operand | d.items()  (or2)",  lambda d, o: o | d.items())
probe("d.items() | operand  (or1)",  lambda d, o: d.items() | o)
probe("d.items() - operand  (sub1)", lambda d, o: d.items() - o)
probe("operand - d.items()  (rsub)", lambda d, o: set(o) - d.items())
probe("d.items() & operand  (and)",  lambda d, o: d.items() & o)

poc_rss.py — availability consequence

import sys, gc, resource
from multidict import CIMultiDict

def rss_mb():
    r = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
    return r / (1024 * 1024) if sys.platform == "darwin" else r / 1024

d = CIMultiDict(); d["seed"] = "x"
gc.collect(); print(f"start RSS = {rss_mb():.1f} MB")
for i in range(200):
    operand = [(f"k{i}_{j}", f"v{i}_{j}") for j in range(50000)]
    _ = operand | d.items()
    del operand
    gc.collect()                     # prove GC cannot reclaim the leak
    if (i + 1) % 40 == 0:
        print(f"after {(i+1)*50000:>9,} elements: RSS = {rss_mb():.1f} MB")

Execution Steps

python3 -m venv venv (CPython 3.10+).
./venv/bin/pip install "multidict==6.9.0" (installs the C-extension wheel).
From a directory that is not a multidict checkout, run each script with ./venv/bin/python.

Actual Execution Evidence

[or2  operand | items] leaked strong refs = 100000
[sub1 items - operand] leaked strong refs = 100000
[and2 items & operand] leaked strong refs = 0        <- control

operand | d.items()  (or2)          leaked=50000
d.items() | operand  (or1)          leaked=0
d.items() - operand  (sub1)         leaked=50000
operand - d.items()  (rsub)         leaked=0
d.items() & operand  (and)          leaked=0

start RSS = 15.6 MB
after 2,000,000 elements: RSS = 288.1 MB
after 6,000,000 elements: RSS = 776.8 MB
after 10,000,000 elements: RSS = 1266.8 MB   (gc.collect() every iteration)

Version-boundary evidence

Same poc_dispatch.py, PyPI wheels, identical environment. Last-clean is 6.6.4; first-affected is 6.7.0:

6.6.4 : or2=0      sub1=0      others=0   (clean, last 6.6.x)
6.7.0 : or2=50000  sub1=50000  others=0   (AFFECTED, first)
6.9.0 : or2=50000  sub1=50000  others=0   (affected)

The clean 6.6.x releases return correct set-operation results, so the zero leak reflects correct memory management, not a broken path.

Analysis of Results

The operand holds exactly N references to one sentinel value; after the union its refcount rises by another N and stays there post-GC, so each element leaked one strong reference. Subtraction shows the identical delta. The intersection control, which clears identity and value, leaks zero; the only code difference is the two missing Py_CLEAR calls, so the leak is caused by that omission and not the harness. RSS climbs from 15.6 MB to 1266.8 MB (~250 MB per 2M elements) despite per-iteration GC, confirming the objects are unreachable by the cyclic collector.

Impact

A process that evaluates items-view unions or subtractions over remote-influenced operands leaks one identity plus one value object per element, permanently. In the aio-libs stack multidict backs HTTP headers and query strings, so an attacker who enlarges the operand (for example, many repeated header items compared against a fixed allow/deny set) forces steady, unrecoverable heap growth and can eventually exhaust memory in a long-lived server. This is an availability defect only; results stay correct and no data is exposed.

Reachability depends on the application evaluating operand | view.items() (reflected union) or view.items() - operand (subtraction) over a sequence of 2-tuples whose count is remote-influenced. The forward union view.items() | operand routes to or1_impl, which clears correctly and does not leak; a non-tuple operand element takes the parse_item early-return and does not leak. Set algebra over items views is not the most common multidict usage, which bounds exposure and is why this is Medium, not High. This is distinct from PR #1413, which fixed a temporary-tuple leak in the second loop and did not release these per-element objects.

Remediation

Recommended fix. Clear the two per-element references at the end of the first parse loop in both functions, exactly as every sibling path does. In or2_impl (views.h:575) and sub1_impl (views.h:696), replace the lone Py_CLEAR(arg); with:

    Py_CLEAR(arg);
    Py_CLEAR(identity);
    Py_CLEAR(value);

This is an in-repo change to a static internal function; it alters no public API, type, or signature, and asks callers to change nothing. A leak test in the existing tests/test_leaks.py style would lock it in.

Workaround. Avoid operand | view.items() and view.items() - operand on attacker-influenced operands, or install with MULTIDICT_NO_EXTENSIONS=1 to use the unaffected pure-Python build.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.9.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "multidict"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0"
            },
            {
              "fixed": "6.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:40:58Z",
    "nvd_published_at": "2026-10-02T21:16:54Z",
    "severity": "MODERATE"
  },
  "details": "## Description\n\nA reference leak in the items-view union and subtraction operators of aio-libs/multidict 6.7.0 through 6.9.0 (C extension) lets a remote client drive unbounded, unreclaimable memory growth by having each operand element leak one key-identity object and one value object. The reflected-union path (`operand | d.items()`, `multidict_itemsview_or2_impl`) and the subtraction path (`d.items() - operand`, `multidict_itemsview_sub1_impl`) parse each element into new strong references but release only the tuple wrapper, never the identity and value. Servers in the aio-libs stack build these views over attacker-supplied HTTP headers and query strings, so the operand size is under remote control. Forced garbage collection does not recover the leaked objects, so resident memory rises monotonically until the process is killed.\n\n---\n\n## Root Cause\n\n`_multidict_itemsview_parse_item()` returns **new** references: a fresh identity via `md_calc_identity()` and a fresh value via `Py_NewRef()`. The `or2_impl` first parse loop requests both but clears only `arg`:\n\n```c\n// views.h:565 \u2014 or2_impl first parse loop\nwhile ((st = PyIter_NextItem(iter, \u0026arg)) \u003e 0) {\n    int tmp = _multidict_itemsview_parse_item(\n        self, arg, \u0026identity, NULL, \u0026value);   // identity + value: new refs\n    if (tmp \u003c 0) goto fail;\n    else if (tmp \u003e 0) {\n        if (_set_add(tmp_set, identity, value) \u003c 0) goto fail;\n    }\n    Py_CLEAR(arg);                             // :575 clears arg ONLY\n}\n```\n\n`_set_add()` builds its own tuple with `PyTuple_Pack` and `Py_DECREF`s it, so it never borrows the loop\u0027s `identity`/`value`. On the next iteration those variables are overwritten, so the previous references are lost permanently. The `sub1_impl` first loop (`:686-696`) has the identical omission.\n\nThis is an editing slip, not an ownership contract: every sibling path clears all three references per iteration, `and1_impl` (`:304-306`), `and2_impl` (`:389-391`), `or1_impl` (`:506-508`), and the second (`md_next`) loops of both functions (`:605-607`, `:726-728`). PR #1413 added a `Py_DECREF(tpl)` to the *second* loop of `or2`/`sub1`, fixing a different temporary-tuple leak; it never touched the first parse loop, so this leak remains on `master`.\n\n`views.h` is byte-identical between `v6.6.0` and `v6.7.0`, yet 6.6.4 does not leak and 6.7.0 does. The regression is behavioural, introduced by a key-identity ownership change in `hashtable.h` across that boundary that made `md_calc_identity()` return a fresh strong reference the unchanged parse loop never releases.\n\n---\n\n## Reproduction Environment\n\n| Item | Value |\n|------|-------|\n| **Runtime** | CPython 3.14.6 |\n| **multidict** | 6.9.0 (PyPI binary wheel, C extension) |\n| **OS** | macOS (darwin 25.6.0, arm64) |\n\n---\n\n## Proof of Concept\n\n### POC Source Code\n\n#### poc_refcount.py \u2014 leak proof with intersection control\n\n```python\nimport sys, gc\nfrom multidict import CIMultiDict\n\ndef probe(name, run_op):\n    d = CIMultiDict(); d[\"seed\"] = \"x\"\n    value = object()                 # unique sentinel\n    N = 100000\n    operand = [(\"k%d\" % i, value) for i in range(N)]\n    gc.collect(); before = sys.getrefcount(value)\n    run_op(d, operand)\n    gc.collect(); after = sys.getrefcount(value)\n    print(f\"[{name}] leaked strong refs = {after - before}\")\n\nprobe(\"or2  operand | items\", lambda d, o: o | d.items())    # reflected union\nprobe(\"sub1 items - operand\", lambda d, o: d.items() - o)    # subtraction\nprobe(\"and2 items \u0026 operand\", lambda d, o: d.items() \u0026 o)    # CONTROL: clears, expect 0\n```\n\n#### poc_dispatch.py \u2014 maps which paths leak\n\n```python\nimport sys, gc\nfrom multidict import CIMultiDict\n\ndef probe(name, fn):\n    d = CIMultiDict(); d[\"seed\"] = \"x\"\n    v = object(); N = 50000\n    operand = [(\"k%d\" % i, v) for i in range(N)]\n    gc.collect(); before = sys.getrefcount(v)\n    fn(d, operand); gc.collect(); after = sys.getrefcount(v)\n    print(f\"{name:35s} leaked={after - before}\")\n\nprobe(\"operand | d.items()  (or2)\",  lambda d, o: o | d.items())\nprobe(\"d.items() | operand  (or1)\",  lambda d, o: d.items() | o)\nprobe(\"d.items() - operand  (sub1)\", lambda d, o: d.items() - o)\nprobe(\"operand - d.items()  (rsub)\", lambda d, o: set(o) - d.items())\nprobe(\"d.items() \u0026 operand  (and)\",  lambda d, o: d.items() \u0026 o)\n```\n\n#### poc_rss.py \u2014 availability consequence\n\n```python\nimport sys, gc, resource\nfrom multidict import CIMultiDict\n\ndef rss_mb():\n    r = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss\n    return r / (1024 * 1024) if sys.platform == \"darwin\" else r / 1024\n\nd = CIMultiDict(); d[\"seed\"] = \"x\"\ngc.collect(); print(f\"start RSS = {rss_mb():.1f} MB\")\nfor i in range(200):\n    operand = [(f\"k{i}_{j}\", f\"v{i}_{j}\") for j in range(50000)]\n    _ = operand | d.items()\n    del operand\n    gc.collect()                     # prove GC cannot reclaim the leak\n    if (i + 1) % 40 == 0:\n        print(f\"after {(i+1)*50000:\u003e9,} elements: RSS = {rss_mb():.1f} MB\")\n```\n\n### Execution Steps\n\n1. `python3 -m venv venv` (CPython 3.10+).\n2. `./venv/bin/pip install \"multidict==6.9.0\"` (installs the C-extension wheel).\n3. From a directory that is **not** a multidict checkout, run each script with `./venv/bin/python`.\n\n### Actual Execution Evidence\n\n```\n[or2  operand | items] leaked strong refs = 100000\n[sub1 items - operand] leaked strong refs = 100000\n[and2 items \u0026 operand] leaked strong refs = 0        \u003c- control\n```\n\n```\noperand | d.items()  (or2)          leaked=50000\nd.items() | operand  (or1)          leaked=0\nd.items() - operand  (sub1)         leaked=50000\noperand - d.items()  (rsub)         leaked=0\nd.items() \u0026 operand  (and)          leaked=0\n```\n\n```\nstart RSS = 15.6 MB\nafter 2,000,000 elements: RSS = 288.1 MB\nafter 6,000,000 elements: RSS = 776.8 MB\nafter 10,000,000 elements: RSS = 1266.8 MB   (gc.collect() every iteration)\n```\n\n### Version-boundary evidence\n\nSame `poc_dispatch.py`, PyPI wheels, identical environment. Last-clean is `6.6.4`; first-affected is `6.7.0`:\n\n```\n6.6.4 : or2=0      sub1=0      others=0   (clean, last 6.6.x)\n6.7.0 : or2=50000  sub1=50000  others=0   (AFFECTED, first)\n6.9.0 : or2=50000  sub1=50000  others=0   (affected)\n```\n\nThe clean 6.6.x releases return correct set-operation results, so the zero leak reflects correct memory management, not a broken path.\n\n### Analysis of Results\n\nThe operand holds exactly `N` references to one sentinel value; after the union its refcount rises by another `N` and stays there post-GC, so each element leaked one strong reference. Subtraction shows the identical delta. The intersection control, which clears `identity` and `value`, leaks zero; the only code difference is the two missing `Py_CLEAR` calls, so the leak is caused by that omission and not the harness. RSS climbs from 15.6 MB to 1266.8 MB (~250 MB per 2M elements) despite per-iteration GC, confirming the objects are unreachable by the cyclic collector.\n\n---\n\n## Impact\n\nA process that evaluates items-view unions or subtractions over remote-influenced operands leaks one identity plus one value object per element, permanently. In the aio-libs stack multidict backs HTTP headers and query strings, so an attacker who enlarges the operand (for example, many repeated header items compared against a fixed allow/deny set) forces steady, unrecoverable heap growth and can eventually exhaust memory in a long-lived server. This is an availability defect only; results stay correct and no data is exposed.\n\nReachability depends on the application evaluating `operand | view.items()` (reflected union) or `view.items() - operand` (subtraction) over a sequence of 2-tuples whose count is remote-influenced. The forward union `view.items() | operand` routes to `or1_impl`, which clears correctly and does not leak; a non-tuple operand element takes the `parse_item` early-return and does not leak. Set algebra over items views is not the most common multidict usage, which bounds exposure and is why this is Medium, not High. This is distinct from PR #1413, which fixed a temporary-tuple leak in the second loop and did not release these per-element objects.\n\n---\n\n## Remediation\n\n**Recommended fix.** Clear the two per-element references at the end of the first parse loop in both functions, exactly as every sibling path does. In `or2_impl` (`views.h:575`) and `sub1_impl` (`views.h:696`), replace the lone `Py_CLEAR(arg);` with:\n\n```c\n    Py_CLEAR(arg);\n    Py_CLEAR(identity);\n    Py_CLEAR(value);\n```\n\nThis is an in-repo change to a static internal function; it alters no public API, type, or signature, and asks callers to change nothing. A leak test in the existing `tests/test_leaks.py` style would lock it in.\n\n**Workaround.** Avoid `operand | view.items()` and `view.items() - operand` on attacker-influenced operands, or install with `MULTIDICT_NO_EXTENSIONS=1` to use the unaffected pure-Python build.\n\n---",
  "id": "GHSA-54p9-h82j-f925",
  "modified": "2026-10-05T23:40:58Z",
  "published": "2026-10-05T23:40:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/multidict/security/advisories/GHSA-54p9-h82j-f925"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104874"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/multidict/commit/350b4a07bf8ff851b6d7544e81b1c748bdc74c40"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aio-libs/multidict"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/multidict/releases/tag/v6.9.1"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Multidict: Reference leak in CIMultiDict/MultiDict items-view union and subtraction"
}

GHSA-553M-XCVQ-64WH

Vulnerability from github – Published: 2026-01-31 12:30 – Updated: 2026-06-02 15:31

Details

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

dmaengine: lpc18xx-dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

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-71188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-31T12:16:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: lpc18xx-dmamux: fix device leak on route allocation\n\nMake sure to drop the reference taken when looking up the DMA mux\nplatform device during route allocation.\n\nNote that holding a reference to a device does not prevent its driver\ndata from going away so there is no point in keeping the reference.",
  "id": "GHSA-553m-xcvq-64wh",
  "modified": "2026-06-02T15:31:51Z",
  "published": "2026-01-31T12:30:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71188"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e47d80f6720f0224efd19bcf081d39637569c10"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d396ebfb3049a2b5fac51d2c967db5114b685e8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/499ddae78c4baa9b94df76b2d2eb6b150d15377f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/992eb8055a6e5dbb808672d20d68e60d5a89b12b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9fba97baa520c9446df51a64708daf27c5a7ed32"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/adef147a8d8c3d767abf88ad2c381ffab2993086"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4d63059dee7e7cae0c4d9a532ed558bc90efb55"
    }
  ],
  "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-5546-CR76-J66R

Vulnerability from github – Published: 2024-12-29 09:30 – Updated: 2025-01-06 18:31

Details

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

udmabuf: fix memory leak on last export_udmabuf() error path

In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a dma_buf owning the udmabuf has already been created; but the error handling in udmabuf_create() will tear down the udmabuf without doing anything about the containing dma_buf.

This leaves a dma_buf in memory that contains a dangling pointer; though that doesn't seem to lead to anything bad except a memory leak.

Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we can give it different error handling.

Note that the shape of this code changed a lot in commit 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios"); but the memory leak seems to have existed since the introduction of udmabuf.

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-2024-56712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-29T09:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: fix memory leak on last export_udmabuf() error path\n\nIn export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a\ndma_buf owning the udmabuf has already been created; but the error handling\nin udmabuf_create() will tear down the udmabuf without doing anything about\nthe containing dma_buf.\n\nThis leaves a dma_buf in memory that contains a dangling pointer; though\nthat doesn\u0027t seem to lead to anything bad except a memory leak.\n\nFix it by moving the dma_buf_fd() call out of export_udmabuf() so that we\ncan give it different error handling.\n\nNote that the shape of this code changed a lot in commit 5e72b2b41a21\n(\"udmabuf: convert udmabuf driver to use folios\"); but the memory leak\nseems to have existed since the introduction of udmabuf.",
  "id": "GHSA-5546-cr76-j66r",
  "modified": "2025-01-06T18:31:01Z",
  "published": "2024-12-29T09:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56712"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c9fc8428d4255c2128da9c4d5cd92e554d0150cf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f49856f525acd5bef52ae28b7da2e001bbe7439e"
    }
  ],
  "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"
    }
  ]
}

CWE-401

Missing Release of Memory after Effective Lifetime

GHSA-5337-PR68-XWQF

GHSA-536V-Q9W2-W76R

GHSA-53CC-XH3P-4X9V

GHSA-53CW-GGRV-83HG

GHSA-53HJ-G53Q-MPCC

GHSA-53QV-XVFG-RJR9

GHSA-54JF-P4CR-5XJ6

GHSA-54P9-H82J-F925

Description

Root Cause

Reproduction Environment

Proof of Concept

POC Source Code

poc_refcount.py — leak proof with intersection control

poc_dispatch.py — maps which paths leak

poc_rss.py — availability consequence

Execution Steps

Actual Execution Evidence

Version-boundary evidence

Analysis of Results

Impact

Remediation

GHSA-553M-XCVQ-64WH

GHSA-5546-CR76-J66R

Mitigation MIT-41

Mitigation

Mitigation