CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6769 vulnerabilities reference this CWE, most recent first.
GHSA-HH96-P296-X7M4
Vulnerability from github – Published: 2024-05-17 12:31 – Updated: 2024-07-03 18:42In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list.
Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming in from PC:
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.
{
"affected": [],
"aliases": [
"CVE-2024-27405"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T12:15:10Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs\n\nIt is observed sometimes when tethering is used over NCM with Windows 11\nas host, at some instances, the gadget_giveback has one byte appended at\nthe end of a proper NTB. When the NTB is parsed, unwrap call looks for\nany leftover bytes in SKB provided by u_ether and if there are any pending\nbytes, it treats them as a separate NTB and parses it. But in case the\nsecond NTB (as per unwrap call) is faulty/corrupt, all the datagrams that\nwere parsed properly in the first NTB and saved in rx_list are dropped.\n\nAdding a few custom traces showed the following:\n[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:\nreq 000000003868811a length 1025/16384 zsI ==\u003e 0\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10\n[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames\n\nIn this case, the giveback is of 1025 bytes and block length is 1024.\nThe rest 1 byte (which is 0x00) won\u0027t be parsed resulting in drop of\nall datagrams in rx_list.\n\nSame is case with packets of size 2048:\n[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:\nreq 0000000011dfd96e length 2049/16384 zsI ==\u003e 0\n[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800\n\nLecroy shows one byte coming in extra confirming that the byte is coming\nin from PC:\n\n Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)\n - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)\n --- Packet 4063861\n Data(1024 bytes)\n Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)\n --- Packet 4063863\n Data(1 byte)\n Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)\n\nAccording to Windows driver, no ZLP is needed if wBlockLength is non-zero,\nbecause the non-zero wBlockLength has already told the function side the\nsize of transfer to be expected. However, there are in-market NCM devices\nthat rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.\nTo deal with such devices, it pads an extra 0 at end so the transfer is no\nlonger multiple of wMaxPacketSize.",
"id": "GHSA-hh96-p296-x7m4",
"modified": "2024-07-03T18:42:21Z",
"published": "2024-05-17T12:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27405"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"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-HH9V-PV5P-4675
Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31Substance3D - Stager versions 3.1.0 and earlier are affected by a NULL Pointer Dereference vulnerability that could result in an application denial-of-service. An attacker could exploit this vulnerability to crash the application, leading to a denial-of-service condition. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2025-21155"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T18:15:27Z",
"severity": "MODERATE"
},
"details": "Substance3D - Stager versions 3.1.0 and earlier are affected by a NULL Pointer Dereference vulnerability that could result in an application denial-of-service. An attacker could exploit this vulnerability to crash the application, leading to a denial-of-service condition. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-hh9v-pv5p-4675",
"modified": "2025-02-11T18:31:36Z",
"published": "2025-02-11T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21155"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/substance3d_stager/apsb25-09.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHHP-JPJM-PG9W
Vulnerability from github – Published: 2022-05-14 03:43 – Updated: 2022-05-14 03:43ccnl-ext-mgmt.c in CCN-lite before 2.00 allows context-dependent attackers to have unspecified impact by leveraging missing NULL pointer checks after ccnl_malloc.
{
"affected": [],
"aliases": [
"CVE-2017-12472"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-07T17:29:00Z",
"severity": "CRITICAL"
},
"details": "ccnl-ext-mgmt.c in CCN-lite before 2.00 allows context-dependent attackers to have unspecified impact by leveraging missing NULL pointer checks after ccnl_malloc.",
"id": "GHSA-hhhp-jpjm-pg9w",
"modified": "2022-05-14T03:43:37Z",
"published": "2022-05-14T03:43:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12472"
},
{
"type": "WEB",
"url": "https://github.com/cn-uofbasel/ccn-lite/issues/138"
},
{
"type": "WEB",
"url": "https://github.com/cn-uofbasel/ccn-lite/releases/tag/2.0.0"
}
],
"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-HHJ3-J6PG-F7MV
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.
{
"affected": [],
"aliases": [
"CVE-2025-38100"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/iopl: Cure TIF_IO_BITMAP inconsistencies\n\nio_bitmap_exit() is invoked from exit_thread() when a task exists or\nwhen a fork fails. In the latter case the exit_thread() cleans up\nresources which were allocated during fork().\n\nio_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up\nin tss_update_io_bitmap(). tss_update_io_bitmap() operates on the\ncurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,\ntss_update_io_bitmap() crashes with a NULL pointer dereference.\n\nThere are two issues, which lead to that problem:\n\n 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when\n the task, which is cleaned up, is not the current task. That\u0027s a\n clear indicator for a cleanup after a failed fork().\n\n 2) A task should not have TIF_IO_BITMAP set and neither a bitmap\n installed nor IOPL emulation level 3 activated.\n\n This happens when a kernel thread is created in the context of\n a user space thread, which has TIF_IO_BITMAP set as the thread\n flags are copied and the IO bitmap pointer is cleared.\n\n Other than in the failed fork() case this has no impact because\n kernel threads including IO workers never return to user space and\n therefore never invoke tss_update_io_bitmap().\n\nCure this by adding the missing cleanups and checks:\n\n 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if\n the to be cleaned up task is not the current task.\n\n 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user\n space forks it is set later, when the IO bitmap is inherited in\n io_bitmap_share().\n\nFor paranoia sake, add a warning into tss_update_io_bitmap() to catch\nthe case, when that code is invoked with inconsistent state.",
"id": "GHSA-hhj3-j6pg-f7mv",
"modified": "2026-05-12T15:30:53Z",
"published": "2025-07-03T09:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38100"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d64b7b05a827f98d068f412969eef65489b0cf03"
},
{
"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:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHMC-QRCV-X7HV
Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-08-12 21:31In the Linux kernel, the following vulnerability has been resolved:
tty: serial: pch_uart: add check for dma_alloc_coherent()
Add a check for dma_alloc_coherent() failure to prevent a potential NULL pointer dereference in dma_handle_rx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.
{
"affected": [],
"aliases": [
"CVE-2026-64234"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T16:16:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: pch_uart: add check for dma_alloc_coherent()\n\nAdd a check for dma_alloc_coherent() failure to prevent a potential\nNULL pointer dereference in dma_handle_rx(). Properly release DMA\nchannels and the PCI device reference using a goto ladder if the\nallocation fails.",
"id": "GHSA-hhmc-qrcv-x7hv",
"modified": "2026-08-12T21:31:08Z",
"published": "2026-07-24T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64234"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f2e2a240dc1846e049bc67e9c3cdf5b031d08bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66f8bfea055b23719b4fd6ce207c44de37d82a59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dd5c0ea139b586ad5a091677056dafd405cfe82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fe472c1bbbe238e91141f7cabc1226e96a60d43"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/760df81763b391bb5f0dcb0b7597b736da753ae4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d846df2dfbc2469a688833b4cc4f8aa80672bde8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8d53a343ebe74274ca17b1e1993042e99f8c863"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/daea997bb244aeb50cbb2e5e075fb446a6cf068f"
}
],
"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-HHMV-6RQC-QRC8
Vulnerability from github – Published: 2025-04-14 15:31 – Updated: 2026-06-26 00:32A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.
{
"affected": [],
"aliases": [
"CVE-2025-32912"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-14T15:15:25Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.",
"id": "GHSA-hhmv-6rqc-qrc8",
"modified": "2026-06-26T00:32:00Z",
"published": "2025-04-14T15:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32912"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:7505"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-32912"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2359356"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/434"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00036.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHP5-2M4Q-MMRP
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function params_dump() located in abc.c. It allows an attacker to cause Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2021-39590"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function params_dump() located in abc.c. It allows an attacker to cause Denial of Service.",
"id": "GHSA-hhp5-2m4q-mmrp",
"modified": "2022-05-24T19:15:05Z",
"published": "2022-05-24T19:15:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39590"
},
{
"type": "WEB",
"url": "https://github.com/matthiaskramm/swftools/issues/137"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HHP7-VJW4-5J8V
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2026-10-09 00:31There's a flaw in binutils /bfd/pef.c. An attacker who is able to submit a crafted input file to be processed by the objdump program could cause a null pointer dereference. The greatest threat from this flaw is to application availability. This flaw affects binutils versions prior to 2.34.
{
"affected": [],
"aliases": [
"CVE-2020-35495"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-04T15:15:00Z",
"severity": "MODERATE"
},
"details": "There\u0027s a flaw in binutils /bfd/pef.c. An attacker who is able to submit a crafted input file to be processed by the objdump program could cause a null pointer dereference. The greatest threat from this flaw is to application availability. This flaw affects binutils versions prior to 2.34.",
"id": "GHSA-hhp7-vjw4-5j8v",
"modified": "2026-10-09T00:31:06Z",
"published": "2022-05-24T17:37:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35495"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1911441"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4KOK3QWSVOUJWJ54HVGIFWNLWQ5ZY4S6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4KOK3QWSVOUJWJ54HVGIFWNLWQ5ZY4S6"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-24"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210212-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHRC-J8PX-RCVJ
Vulnerability from github – Published: 2023-03-01 15:30 – Updated: 2023-03-10 18:30libde265 v1.0.10 was discovered to contain a NULL pointer dereference in the ff_hevc_put_weighted_pred_avg_8_sse function at sse-motion.cc. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input file.
{
"affected": [],
"aliases": [
"CVE-2023-24754"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-01T15:15:00Z",
"severity": "MODERATE"
},
"details": "libde265 v1.0.10 was discovered to contain a NULL pointer dereference in the ff_hevc_put_weighted_pred_avg_8_sse function at sse-motion.cc. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input file.",
"id": "GHSA-hhrc-j8px-rcvj",
"modified": "2023-03-10T18:30:21Z",
"published": "2023-03-01T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24754"
},
{
"type": "WEB",
"url": "https://github.com/strukturag/libde265/issues/382"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00004.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHXQ-R4W4-4F7M
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2024-12-20 15:30In the Linux kernel, the following vulnerability has been resolved:
pmdomain: arm: Fix NULL dereference on scmi_perf_domain removal
On unloading of the scmi_perf_domain module got the below splat, when in the DT provided to the system under test the '#power-domain-cells' property was missing. Indeed, this particular setup causes the probe to bail out early without giving any error, which leads to the ->remove() callback gets to run too, but without all the expected initialized structures in place.
Add a check and bail out early on remove too.
Call trace: scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain] scmi_dev_remove+0x28/0x40 [scmi_core] device_remove+0x54/0x90 device_release_driver_internal+0x1dc/0x240 driver_detach+0x58/0xa8 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x70 scmi_driver_unregister+0x28/0x180 [scmi_core] scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain] __arm64_sys_delete_module+0x1a8/0x2c0 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0xb8 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80) ---[ end trace 0000000000000000 ]---
{
"affected": [],
"aliases": [
"CVE-2024-26784"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: arm: Fix NULL dereference on scmi_perf_domain removal\n\nOn unloading of the scmi_perf_domain module got the below splat, when in\nthe DT provided to the system under test the \u0027#power-domain-cells\u0027 property\nwas missing. Indeed, this particular setup causes the probe to bail out\nearly without giving any error, which leads to the -\u003eremove() callback gets\nto run too, but without all the expected initialized structures in place.\n\nAdd a check and bail out early on remove too.\n\n Call trace:\n scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain]\n scmi_dev_remove+0x28/0x40 [scmi_core]\n device_remove+0x54/0x90\n device_release_driver_internal+0x1dc/0x240\n driver_detach+0x58/0xa8\n bus_remove_driver+0x78/0x108\n driver_unregister+0x38/0x70\n scmi_driver_unregister+0x28/0x180 [scmi_core]\n scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain]\n __arm64_sys_delete_module+0x1a8/0x2c0\n invoke_syscall+0x50/0x128\n el0_svc_common.constprop.0+0x48/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x34/0xb8\n el0t_64_sync_handler+0x100/0x130\n el0t_64_sync+0x190/0x198\n Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80)\n ---[ end trace 0000000000000000 ]---",
"id": "GHSA-hhxq-r4w4-4f7m",
"modified": "2024-12-20T15:30:44Z",
"published": "2024-04-04T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26784"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb5555d422d0fc325e1574a7353d3c616f82d8b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6aaf131e4d4a9a26040ecc018eb70ab8b3d355d"
}
],
"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"
}
]
}
Mitigation MIT-56
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Mitigation
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Mitigation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
No CAPEC attack patterns related to this CWE.