CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
7038 vulnerabilities reference this CWE, most recent first.
GHSA-2PCW-FG2M-836W
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2026-10-15 03:34In the Linux kernel, the following vulnerability has been resolved:
mm/migrate: fix shmem xarray update during migration
A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping.
In __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xas_store() (see [1] for a userspace reproduction). Fix it by only using folio_test_swapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update.
[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/
Note: In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is used to get swap_cache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at __xa_store(), since !folio_test_anon() is true and folio->mapping is NULL. But fortunately, its caller split_huge_page_to_list_to_order() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.
{
"affected": [],
"aliases": [
"CVE-2025-22015"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate: fix shmem xarray update during migration\n\nA shmem folio can be either in page cache or in swap cache, but not at the\nsame time. Namely, once it is in swap cache, folio-\u003emapping should be\nNULL, and the folio is no longer in a shmem mapping.\n\nIn __folio_migrate_mapping(), to determine the number of xarray entries to\nupdate, folio_test_swapbacked() is used, but that conflates shmem in page\ncache case and shmem in swap cache case. It leads to xarray multi-index\nentry corruption, since it turns a sibling entry to a normal entry during\nxas_store() (see [1] for a userspace reproduction). Fix it by only using\nfolio_test_swapcache() to determine whether xarray is storing swap cache\nentries or not to choose the right number of xarray entries to update.\n\n[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/\n\nNote:\nIn __split_huge_page(), folio_test_anon() \u0026\u0026 folio_test_swapcache() is\nused to get swap_cache address space, but that ignores the shmem folio in\nswap cache case. It could lead to NULL pointer dereferencing when a\nin-swap-cache shmem folio is split at __xa_store(), since\n!folio_test_anon() is true and folio-\u003emapping is NULL. But fortunately,\nits caller split_huge_page_to_list_to_order() bails out early with EBUSY\nwhen folio-\u003emapping is NULL. So no need to take care of it here.",
"id": "GHSA-2pcw-fg2m-836w",
"modified": "2026-10-15T03:34:45Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22015"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29124ae980e2860f0eec7355949d3d3292ee81da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49100c0b070e900f87c8fac3be9b9ef8a30fa673"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60cf233b585cdf1f3c5e52d1225606b86acd08b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75cfb92eb63298d717b6b0118f91ba12c4fcfeb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c057ee03f751d6cecf7ee64f52f6545d94082aaa"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-2PHP-7PRQ-766P
Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2023-08-17 15:30A Null Pointer Dereference vulnerability exits in ffjpeg d5cfd49 (2021-12-06) in bmp_load(). When the size information in metadata of the bmp is out of range, it returns without assign memory buffer to pb->pdata and did not exit the program. So the program crashes when it tries to access the pb->data, in jfif_encode() at jfif.c:763. This is due to the incomplete patch for CVE-2020-13438.
{
"affected": [],
"aliases": [
"CVE-2021-45385"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-11T16:15:00Z",
"severity": "MODERATE"
},
"details": "A Null Pointer Dereference vulnerability exits in ffjpeg d5cfd49 (2021-12-06) in bmp_load(). When the size information in metadata of the bmp is out of range, it returns without assign memory buffer to `pb-\u003epdata` and did not exit the program. So the program crashes when it tries to access the pb-\u003edata, in jfif_encode() at jfif.c:763. This is due to the incomplete patch for CVE-2020-13438.",
"id": "GHSA-2php-7prq-766p",
"modified": "2023-08-17T15:30:19Z",
"published": "2022-02-12T00:00:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45385"
},
{
"type": "WEB",
"url": "https://github.com/rockcarry/ffjpeg/issues/47"
},
{
"type": "WEB",
"url": "https://github.com/rockcarry/ffjpeg/pull/48"
}
],
"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-2PJX-4J7G-WF3F
Vulnerability from github – Published: 2022-05-14 03:36 – Updated: 2022-05-14 03:36A NULL pointer access issue was discovered in Asterisk 15.x through 15.2.1. The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number, these desired ones are still stored internally. When an RTP packet was received, this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example, the payload number resulted in a video codec but the stream carried audio), a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of that type would always exist.
{
"affected": [],
"aliases": [
"CVE-2018-7285"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-22T00:29:00Z",
"severity": "HIGH"
},
"details": "A NULL pointer access issue was discovered in Asterisk 15.x through 15.2.1. The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number, these desired ones are still stored internally. When an RTP packet was received, this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example, the payload number resulted in a video codec but the stream carried audio), a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of that type would always exist.",
"id": "GHSA-2pjx-4j7g-wf3f",
"modified": "2022-05-14T03:36:28Z",
"published": "2022-05-14T03:36:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7285"
},
{
"type": "WEB",
"url": "http://downloads.asterisk.org/pub/security/AST-2018-001.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103149"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040415"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2PP7-RWQG-2GCX
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-12-30 21:30In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
{
"affected": [],
"aliases": [
"CVE-2021-47409"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.",
"id": "GHSA-2pp7-rwqg-2gcx",
"modified": "2024-12-30T21:30:46Z",
"published": "2024-05-21T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47409"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2754fa3b73df7d0ae042f3ed6cfd9df9042f6262"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/337f00a0bc62d7cb7d10ec0b872c79009a1641df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b7f4a0eb92bf37bea4cd838c7f83ea42823ca8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/856e6e8e0f9300befa87dde09edb578555c99a82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b9c1c33e51d0959f2aec573dfbac0ffd3f5c0b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7182993dd8e09f96839ddc3ac54f9b37370d282"
}
],
"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-2PPH-66PX-9X3W
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2025-11-26 18:30In the Linux kernel, the following vulnerability has been resolved:
media: ti: j721e-csi2rx: fix list_del corruption
If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption.
Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error.
This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---
{
"affected": [],
"aliases": [
"CVE-2025-38619"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ti: j721e-csi2rx: fix list_del corruption\n\nIf ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is\nmarked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.\nThis causes the same buffer to be retried in the next iteration, resulting\nin a double list_del() and eventual list corruption.\n\nFix this by removing the buffer from the queue before calling\nvb2_buffer_done() on error.\n\nThis resolves a crash due to list_del corruption:\n[ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA\n[ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048\n[ 37.839761] list_del corruption. next-\u003eprev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)\n[ 37.850799] ------------[ cut here ]------------\n[ 37.855424] kernel BUG at lib/list_debug.c:65!\n[ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul\n[ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY\n[ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)\n[ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114\n[ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114\n[ 37.914059] sp : ffff800080003db0\n[ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000\n[ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122\n[ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0\n[ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a\n[ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720\n[ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea\n[ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568\n[ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff\n[ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000\n[ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d\n[ 37.988832] Call trace:\n[ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)\n[ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4\n[ 38.001419] udma_vchan_complete+0x1e0/0x344\n[ 38.005705] tasklet_action_common+0x118/0x310\n[ 38.010163] tasklet_action+0x30/0x3c\n[ 38.013832] handle_softirqs+0x10c/0x2e0\n[ 38.017761] __do_softirq+0x14/0x20\n[ 38.021256] ____do_softirq+0x10/0x20\n[ 38.024931] call_on_irq_stack+0x24/0x60\n[ 38.028873] do_softirq_own_stack+0x1c/0x40\n[ 38.033064] __irq_exit_rcu+0x130/0x15c\n[ 38.036909] irq_exit_rcu+0x10/0x20\n[ 38.040403] el1_interrupt+0x38/0x60\n[ 38.043987] el1h_64_irq_handler+0x18/0x24\n[ 38.048091] el1h_64_irq+0x6c/0x70\n[ 38.051501] default_idle_call+0x34/0xe0 (P)\n[ 38.055783] do_idle+0x1f8/0x250\n[ 38.059021] cpu_startup_entry+0x34/0x3c\n[ 38.062951] rest_init+0xb4/0xc0\n[ 38.066186] console_on_rootfs+0x0/0x6c\n[ 38.070031] __primary_switched+0x88/0x90\n[ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)\n[ 38.080168] ---[ end trace 0000000000000000 ]---\n[ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt\n[ 38.092197] SMP: stopping secondary CPUs\n[ 38.096139] Kernel Offset: disabled\n[ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b\n[ 38.105202] Memory Limit: none\n[ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---",
"id": "GHSA-2pph-66px-9x3w",
"modified": "2025-11-26T18:30:59Z",
"published": "2025-08-22T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38619"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68e5579f4de12207b23c41b44a4c0778b6c2858f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92d0188f36ca8082af7989d743eb5b44c2d259f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4a8cb0889927d59ebd839458c8f038bc5298ef9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae42c6fe531425ef2f47e82f96851427d24bbf6b"
}
],
"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-2PPM-VR48-8V34
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33Windows Mobile Broadband Driver Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-43559"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T18:15:22Z",
"severity": "MODERATE"
},
"details": "Windows Mobile Broadband Driver Denial of Service Vulnerability",
"id": "GHSA-2ppm-vr48-8v34",
"modified": "2024-10-08T18:33:16Z",
"published": "2024-10-08T18:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43559"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43559"
}
],
"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-2PR3-QRHM-JM7J
Vulnerability from github – Published: 2022-05-14 01:13 – Updated: 2022-05-14 01:13PoDoFo::Impose::PdfTranslator::setSource() in pdftranslator.cpp in PoDoFo 0.9.6 has a NULL pointer dereference that can (for example) be triggered by sending a crafted PDF file to the podofoimpose binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact.
{
"affected": [],
"aliases": [
"CVE-2019-9199"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-26T23:29:00Z",
"severity": "HIGH"
},
"details": "PoDoFo::Impose::PdfTranslator::setSource() in pdftranslator.cpp in PoDoFo 0.9.6 has a NULL pointer dereference that can (for example) be triggered by sending a crafted PDF file to the podofoimpose binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact.",
"id": "GHSA-2pr3-qrhm-jm7j",
"modified": "2022-05-14T01:13:35Z",
"published": "2022-05-14T01:13:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9199"
},
{
"type": "WEB",
"url": "https://github.com/jjanku/podofo/commit/ada821df68fb0bf673840ed525daf4ec709dbfd9"
},
{
"type": "WEB",
"url": "https://github.com/mksdev/podofo/commit/1400a9aaf611299b9a56aa2abeb158918b9743c8"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CIC2EXSSMBT3MY2HY42IIY4BUQS2SVYB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NTJ5AAM6Y4NMSELEH7N5ZG4DNO56BCYF"
},
{
"type": "WEB",
"url": "https://research.loginsoft.com/bugs/null-pointer-dereference-vulnerability-in-setsource-podofo-0-9-6-trunk-r1967"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/podofo/tickets/40"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2PR5-QXG3-PFQF
Vulnerability from github – Published: 2025-08-07 15:33 – Updated: 2025-12-29 18:30openjpeg v 2.5.0 was discovered to contain a NULL pointer dereference via the component /openjp2/dwt.c.
{
"affected": [],
"aliases": [
"CVE-2025-50952"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-07T15:15:32Z",
"severity": "MODERATE"
},
"details": "openjpeg v 2.5.0 was discovered to contain a NULL pointer dereference via the component /openjp2/dwt.c.",
"id": "GHSA-2pr5-qxg3-pfqf",
"modified": "2025-12-29T18:30:18Z",
"published": "2025-08-07T15:33:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50952"
},
{
"type": "WEB",
"url": "https://github.com/uclouvain/openjpeg/issues/1505"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/12/msg00035.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2PRG-GCGC-MM7V
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-11-21 00:30In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mld: avoid panic on init failure
In case of an error during init, in_hw_restart will be set, but it will never get cleared. Instead, we will retry to init again, and then we will act like we are in a restart when we are actually not.
This causes (among others) to a NULL pointer dereference when canceling rx_omi::finished_work, that was not even initialized, because we thought that we are in hw_restart.
Set in_hw_restart to true only if the fw is running, then we know that FW was loaded successfully and we are not going to the retry loop.
{
"affected": [],
"aliases": [
"CVE-2025-38121"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mld: avoid panic on init failure\n\nIn case of an error during init, in_hw_restart will be set, but it will\nnever get cleared.\nInstead, we will retry to init again, and then we will act like we are in a\nrestart when we are actually not.\n\nThis causes (among others) to a NULL pointer dereference when canceling\nrx_omi::finished_work, that was not even initialized, because we thought\nthat we are in hw_restart.\n\nSet in_hw_restart to true only if the fw is running, then we know that\nFW was loaded successfully and we are not going to the retry loop.",
"id": "GHSA-2prg-gcgc-mm7v",
"modified": "2025-11-21T00:30:20Z",
"published": "2025-07-03T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38121"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/960c7e6d388034d219dafffa6da0a5c2ccd5ff30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a26ec8e16958b6dd37dac9daf5fb6978fe0cb0b8"
}
],
"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-2Q2C-9VGR-84GW
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20
{
"affected": [],
"aliases": [
"CVE-2025-22086"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn\u0027t NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that\u0027s wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 \u0026 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn\u0027t match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 \u003c0f\u003e b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n \u003cTASK\u003e\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n __ib_process_cq+0x5a/0x150 [ib_core]\n ib_cq_poll_work+0x31/0x90 [ib_core]\n process_one_work+0x169/0x320\n worker_thread+0x288/0x3a0\n ? work_busy+0xb0/0xb0\n kthread+0xd7/0x1f0\n ? kthreads_online_cpu+0x130/0x130\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork+0x2d/0x50\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork_asm+0x11/0x20\n \u003c/TASK\u003e",
"id": "GHSA-2q2c-9vgr-84gw",
"modified": "2025-11-03T21:33:36Z",
"published": "2025-04-16T15:34:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22086"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b97d77049856865ac5ce8ffbc6e716928310f7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55c65a64aefa6267b964d90e9a4039cb68ec73a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c51a6964b45b6d40027abd77e89cef30d26dc5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/856d9e5d72dc44eca6d5a153581c58fbd84e92e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cad677085274ecf9c7565b5bfc5d2e49acbf174c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d52636eb13ccba448a752964cc6fc49970912874"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc7139b7031d877acd73d7eff55670f22f48cd5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0447ceb8a31d79bee7144f98f9a13f765531e1a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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"
}
]
}
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.