Vulnerability-Lookup

GHSA-PRJQ-F4Q3-FVFR

Vulnerability from github – Published: 2022-11-15 19:05 – Updated: 2024-05-20 19:38

Summary

github.com/russellhaering/gosaml2 is vulnerable to NULL Pointer Dereference

Details

Impact

In versions prior to v0.7.0 it was possible for an attacker to supply an invalid assertion which would trigger a panic due to a nil-pointer dereference.

Patches

The issue was patched in v0.7.0, released on March 2, 2022.

Workarounds

Callers to gosaml2 can use recover() to handle panics to mitigate a potential DoS.

References

See issue #59 for details.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/russellhaering/gosaml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/russellhaering/goxmldsig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-15T19:05:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nIn versions prior to v0.7.0 it was possible for an attacker to supply an invalid assertion which would trigger a panic due to a nil-pointer dereference.\n\n### Patches\nThe issue was patched in v0.7.0, released on March 2, 2022.\n\n### Workarounds\nCallers to `gosaml2` can use `recover()` to handle panics to mitigate a potential DoS.\n\n### References\nSee issue [#59](https://github.com/russellhaering/gosaml2/issues/59) for details.",
  "id": "GHSA-prjq-f4q3-fvfr",
  "modified": "2024-05-20T19:38:33Z",
  "published": "2022-11-15T19:05:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-prjq-f4q3-fvfr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/issues/59"
    },
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/goxmldsig/issues/48"
    },
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/pull/90"
    },
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/commit/66e3b7affd622b8b24ea1e18845f045e46b23424"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/russellhaering/gosaml2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/releases/tag/v0.7.0"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMRUSSELLHAERINGGOSAML2-608302"
    }
  ],
  "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"
    }
  ],
  "summary": "github.com/russellhaering/gosaml2 is vulnerable to NULL Pointer Dereference"
}

GHSA-PRWP-XRV5-5JV3

Vulnerability from github – Published: 2023-08-25 21:30 – Updated: 2023-12-12 15:30

Details

An issue was discovered in Libreswan before 4.12. When an IKEv1 Quick Mode connection configured with ID_IPV4_ADDR or ID_IPV6_ADDR receives an IDcr payload with ID_FQDN, a NULL pointer dereference causes a crash and restart of the pluto daemon. NOTE: the earliest affected version is 4.6.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-38711"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-25T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Libreswan before 4.12. When an IKEv1 Quick Mode connection configured with ID_IPV4_ADDR or ID_IPV6_ADDR receives an IDcr payload with ID_FQDN, a NULL pointer dereference causes a crash and restart of the pluto daemon. NOTE: the earliest affected version is 4.6.",
  "id": "GHSA-prwp-xrv5-5jv3",
  "modified": "2023-12-12T15:30:58Z",
  "published": "2023-08-25T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38711"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libreswan/libreswan/tags"
    },
    {
      "type": "WEB",
      "url": "https://libreswan.org/security/CVE-2023-38711"
    }
  ],
  "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-PV35-9GQP-7Q2C

Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-05-30 12:30

Details

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

RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads

atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt):

value = *(u64 *)payload_addr(pkt);

check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC).

IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path.

Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-46114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T10:16:26Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads\n\natomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c\nunconditionally dereferences 8 bytes at payload_addr(pkt):\n\n    value = *(u64 *)payload_addr(pkt);\n\ncheck_rkey() previously accepted an ATOMIC_WRITE request with pktlen ==\nresid == 0 because the length validation only compared pktlen against\nresid. A remote initiator that sets the RETH length to 0 therefore reaches\natomic_write_reply() with a zero-byte logical payload, and the responder\nreads sizeof(u64) bytes from past the logical end of the packet into\nskb-\u003ehead tailroom, then writes those 8 bytes into the attacker\u0027s MR via\nrxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel\ntailroom per probe (the other 4 bytes are the packet\u0027s own trailing ICRC).\n\nIBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is\nprotocol-invalid. Hoist a strict length check into check_rkey() so the\nresponder never reaches the unchecked dereference, and keep the existing\nWRITE-family length logic for the normal RDMA WRITE path.\n\nReproduced on mainline with an unmodified rxe driver: a sustained\nzero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer\nbytes into the attacker\u0027s MR, including recognisable kernel strings and\npartial kernel-direct-map pointer words.  With this patch applied the\nresponder rejects the PDU and the MR stays all-zero.",
  "id": "GHSA-pv35-9gqp-7q2c",
  "modified": "2026-05-30T12:30:25Z",
  "published": "2026-05-28T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46114"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/105bf79a23b85cf3a761d18a4f3e10ce88526bc1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1114c87aa6f195cf07da55a27b2122ae26557b26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/539cabb7b2d8ba70f55bba91db55faef11c2a6d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ec1ed4747f5f99f8b797bb438c5efd36079fad5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d415fce3fcde6d7aeea6c25362a395b905811452"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PV82-VF69-RQQM

Vulnerability from github – Published: 2022-05-13 01:04 – Updated: 2024-12-13 15:30

Details

systemd-resolved through 233 allows remote attackers to cause a denial of service (daemon crash) via a crafted DNS response with an empty question section.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-9217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-24T05:29:00Z",
    "severity": "HIGH"
  },
  "details": "systemd-resolved through 233 allows remote attackers to cause a denial of service (daemon crash) via a crafted DNS response with an empty question section.",
  "id": "GHSA-pv82-vf69-rqqm",
  "modified": "2024-12-13T15:30:38Z",
  "published": "2022-05-13T01:04:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/systemd/systemd/pull/5998"
    },
    {
      "type": "WEB",
      "url": "https://github.com/systemd/systemd/commit/a924f43f30f9c4acaf70618dd2a055f8b0f166be"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.net/bugs/1621396"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241213-0003"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98677"
    }
  ],
  "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-PVCC-25WC-FRXR

Vulnerability from github – Published: 2022-05-14 03:54 – Updated: 2025-04-20 03:31

Details

The _parse_pat function in the mpegts parser in GStreamer before 1.10.2 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a crafted file.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2016-9813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-01-13T16:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The _parse_pat function in the mpegts parser in GStreamer before 1.10.2 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a crafted file.",
  "id": "GHSA-pvcc-25wc-frxr",
  "modified": "2025-04-20T03:31:12Z",
  "published": "2022-05-14T03:54:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9813"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.gnome.org/show_bug.cgi?id=775120"
    },
    {
      "type": "WEB",
      "url": "https://gstreamer.freedesktop.org/releases/1.10/#1.10.2"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201705-10"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/42162"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2017-0021.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3818"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/12/01/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/12/05/8"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95158"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PVCM-VR92-9WX7

Vulnerability from github – Published: 2024-02-27 21:31 – Updated: 2025-01-08 18:30

Details

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

scsi: qla2xxx: Reserve extra IRQ vectors

Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs.

That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as:

ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode)

max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available.

qla2xxx_queuecommand() tries to find a qpair in the map and crashes:

if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL;

      tag = blk_mq_unique_tag(cmd->request);
      hwq = blk_mq_unique_tag_to_hwq(tag);
      qpair = ha->queue_pair_map[hwq]; # <- HERE

      if (qpair)
              return qla2xxx_mqueuecommand(host, cmd, qpair);

}

BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30

The driver should allocate enough vectors to provide every CPU it's own HW queue and still handle reserved (MB, RSP, ATIO) interrupts.

The change fixes the crash on dual core VM and prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs.

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-2021-46964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T19:04:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Reserve extra IRQ vectors\n\nCommit a6dcfe08487e (\"scsi: qla2xxx: Limit interrupt vectors to number of\nCPUs\") lowers the number of allocated MSI-X vectors to the number of CPUs.\n\nThat breaks vector allocation assumptions in qla83xx_iospace_config(),\nqla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions\ncomputes maximum number of qpairs as:\n\n  ha-\u003emax_qpairs = ha-\u003emsix_count - 1 (MB interrupt) - 1 (default\n                   response queue) - 1 (ATIO, in dual or pure target mode)\n\nmax_qpairs is set to zero in case of two CPUs and initiator mode. The\nnumber is then used to allocate ha-\u003equeue_pair_map inside\nqla2x00_alloc_queues(). No allocation happens and ha-\u003equeue_pair_map is\nleft NULL but the driver thinks there are queue pairs available.\n\nqla2xxx_queuecommand() tries to find a qpair in the map and crashes:\n\n  if (ha-\u003emqenable) {\n          uint32_t tag;\n          uint16_t hwq;\n          struct qla_qpair *qpair = NULL;\n\n          tag = blk_mq_unique_tag(cmd-\u003erequest);\n          hwq = blk_mq_unique_tag_to_hwq(tag);\n          qpair = ha-\u003equeue_pair_map[hwq]; # \u003c- HERE\n\n          if (qpair)\n                  return qla2xxx_mqueuecommand(host, cmd, qpair);\n  }\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP PTI\n  CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G        W         5.10.0-rc1+ #25\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014\n  Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc]\n  RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx]\n  Call Trace:\n   scsi_queue_rq+0x58c/0xa60\n   blk_mq_dispatch_rq_list+0x2b7/0x6f0\n   ? __sbitmap_get_word+0x2a/0x80\n   __blk_mq_sched_dispatch_requests+0xb8/0x170\n   blk_mq_sched_dispatch_requests+0x2b/0x50\n   __blk_mq_run_hw_queue+0x49/0xb0\n   __blk_mq_delay_run_hw_queue+0xfb/0x150\n   blk_mq_sched_insert_request+0xbe/0x110\n   blk_execute_rq+0x45/0x70\n   __scsi_execute+0x10e/0x250\n   scsi_probe_and_add_lun+0x228/0xda0\n   __scsi_scan_target+0xf4/0x620\n   ? __pm_runtime_resume+0x4f/0x70\n   scsi_scan_target+0x100/0x110\n   fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc]\n   process_one_work+0x1ea/0x3b0\n   worker_thread+0x28/0x3b0\n   ? process_one_work+0x3b0/0x3b0\n   kthread+0x112/0x130\n   ? kthread_park+0x80/0x80\n   ret_from_fork+0x22/0x30\n\nThe driver should allocate enough vectors to provide every CPU it\u0027s own HW\nqueue and still handle reserved (MB, RSP, ATIO) interrupts.\n\nThe change fixes the crash on dual core VM and prevents unbalanced QP\nallocation where nr_hw_queues is two less than the number of CPUs.",
  "id": "GHSA-pvcm-vr92-9wx7",
  "modified": "2025-01-08T18:30:40Z",
  "published": "2024-02-27T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46964"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f86d66b38501e3ac66cf2d9f9f8ad6838bad0e6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ecd42dec858b6632c5f024fe13e9ad6c30f2734"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f02d4086a8f36a0e1aaebf559b54cf24a177a486"
    }
  ],
  "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-PVCR-V8J8-J5Q3

Vulnerability from github – Published: 2024-01-09 16:18 – Updated: 2024-01-09 21:52

Summary

Parsing JSON serialized payload without protected field can lead to segfault

Details

Summary

Calling jws.Parse with a JSON serialized payload where the signature field is present while protected is absent can lead to a nil pointer dereference.

Details

This seems to also affect other functions that calls Parse internally, like jws.Verify.

My understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don't require any prior validation.

Based on the stack trace in the PoC, the issue seems to be that the processing done in jws/message.go:UnmarshalJSON() assumes that if a signature field is present, then a protected field is also present. If this is not the case, then the subsequent call to getB64Value(sig.protected) will dereference sig.protected, which is nil.

PoC

Reproducer:

package poc

import (
        "testing"

        "github.com/lestrrat-go/jwx/v2/jws"
)

func TestPOC(t *testing.T) {
        _, _ = jws.Parse([]byte(`{"signature": ""}`))
}

Result:

$ go test        
--- FAIL: TestPOC (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x5fd618]

goroutine 6 [running]:
testing.tRunner.func1.2({0x628800, 0x831030})
        /usr/local/go/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
        /usr/local/go/src/testing/testing.go:1548 +0x397
panic({0x628800?, 0x831030?})
        /usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/lestrrat-go/jwx/v2/jws.getB64Value({0x0?, 0x0?})
        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:484 +0x18
github.com/lestrrat-go/jwx/v2/jws.(*Message).UnmarshalJSON(0xc0000a2140, {0xc0000ec000, 0x11, 0x200})
        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/message.go:323 +0x4ad
encoding/json.(*decodeState).object(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0x16?})
        /usr/local/go/src/encoding/json/decode.go:604 +0x6cc
encoding/json.(*decodeState).value(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0xc00006e630?})
        /usr/local/go/src/encoding/json/decode.go:374 +0x3e
encoding/json.(*decodeState).unmarshal(0xc0000ea028, {0x64fa60?, 0xc0000a2140?})
        /usr/local/go/src/encoding/json/decode.go:181 +0x133
encoding/json.(*Decoder).Decode(0xc0000ea000, {0x64fa60, 0xc0000a2140})
        /usr/local/go/src/encoding/json/stream.go:73 +0x179
github.com/lestrrat-go/jwx/v2/internal/json.Unmarshal({0xc00001a288, 0x11, 0x11}, {0x64fa60, 0xc0000a2140})
        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/internal/json/json.go:26 +0x97
github.com/lestrrat-go/jwx/v2/jws.parseJSON({0xc00001a288, 0x11, 0x11})
        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:588 +0x50
github.com/lestrrat-go/jwx/v2/jws.Parse({0xc00001a288, 0x11, 0x11}, {0x0?, 0xc00006e760?, 0x48450f?})
        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:525 +0x89
poc.TestPOC(0x0?)
        /home/fredrik/src/jwx_poc/poc_test.go:10 +0x57
testing.tRunner(0xc0000e4340, 0x68ef30)
        /usr/local/go/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 1
        /usr/local/go/src/testing/testing.go:1648 +0x3ad
exit status 2
FAIL    poc     0.005s

Impact

The vulnerability can be used to crash / DOS a system doing JWS verification.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lestrrat-go/jwx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.8"
            },
            {
              "fixed": "1.2.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lestrrat-go/jwx/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-09T16:18:48Z",
    "nvd_published_at": "2024-01-09T20:15:43Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nCalling `jws.Parse` with a JSON serialized payload where the `signature` field is present while `protected` is absent can lead to a nil pointer dereference.\n\n### Details\n\nThis seems to also affect other functions that calls `Parse` internally, like `jws.Verify`.\n\nMy understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don\u0027t require any prior validation.\n\nBased on the stack trace in the PoC, the issue seems to be that the processing done in `jws/message.go:UnmarshalJSON()` assumes that if a `signature` field is present, then a `protected` field is also present. If this is not the case, then the subsequent call to `getB64Value(sig.protected)` will dereference `sig.protected`, which is `nil`.\n\n### PoC\n\nReproducer:\n\n```go\npackage poc\n\nimport (\n        \"testing\"\n\n        \"github.com/lestrrat-go/jwx/v2/jws\"\n)\n\nfunc TestPOC(t *testing.T) {\n        _, _ = jws.Parse([]byte(`{\"signature\": \"\"}`))\n}\n```\n\nResult:\n\n```\n$ go test        \n--- FAIL: TestPOC (0.00s)\npanic: runtime error: invalid memory address or nil pointer dereference [recovered]\n        panic: runtime error: invalid memory address or nil pointer dereference\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x5fd618]\n\ngoroutine 6 [running]:\ntesting.tRunner.func1.2({0x628800, 0x831030})\n        /usr/local/go/src/testing/testing.go:1545 +0x238\ntesting.tRunner.func1()\n        /usr/local/go/src/testing/testing.go:1548 +0x397\npanic({0x628800?, 0x831030?})\n        /usr/local/go/src/runtime/panic.go:914 +0x21f\ngithub.com/lestrrat-go/jwx/v2/jws.getB64Value({0x0?, 0x0?})\n        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:484 +0x18\ngithub.com/lestrrat-go/jwx/v2/jws.(*Message).UnmarshalJSON(0xc0000a2140, {0xc0000ec000, 0x11, 0x200})\n        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/message.go:323 +0x4ad\nencoding/json.(*decodeState).object(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0x16?})\n        /usr/local/go/src/encoding/json/decode.go:604 +0x6cc\nencoding/json.(*decodeState).value(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0xc00006e630?})\n        /usr/local/go/src/encoding/json/decode.go:374 +0x3e\nencoding/json.(*decodeState).unmarshal(0xc0000ea028, {0x64fa60?, 0xc0000a2140?})\n        /usr/local/go/src/encoding/json/decode.go:181 +0x133\nencoding/json.(*Decoder).Decode(0xc0000ea000, {0x64fa60, 0xc0000a2140})\n        /usr/local/go/src/encoding/json/stream.go:73 +0x179\ngithub.com/lestrrat-go/jwx/v2/internal/json.Unmarshal({0xc00001a288, 0x11, 0x11}, {0x64fa60, 0xc0000a2140})\n        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/internal/json/json.go:26 +0x97\ngithub.com/lestrrat-go/jwx/v2/jws.parseJSON({0xc00001a288, 0x11, 0x11})\n        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:588 +0x50\ngithub.com/lestrrat-go/jwx/v2/jws.Parse({0xc00001a288, 0x11, 0x11}, {0x0?, 0xc00006e760?, 0x48450f?})\n        /home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:525 +0x89\npoc.TestPOC(0x0?)\n        /home/fredrik/src/jwx_poc/poc_test.go:10 +0x57\ntesting.tRunner(0xc0000e4340, 0x68ef30)\n        /usr/local/go/src/testing/testing.go:1595 +0xff\ncreated by testing.(*T).Run in goroutine 1\n        /usr/local/go/src/testing/testing.go:1648 +0x3ad\nexit status 2\nFAIL    poc     0.005s\n```\n\n### Impact\n\nThe vulnerability can be used to crash / DOS a system doing JWS verification.\n",
  "id": "GHSA-pvcr-v8j8-j5q3",
  "modified": "2024-01-09T21:52:54Z",
  "published": "2024-01-09T16:18:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/security/advisories/GHSA-pvcr-v8j8-j5q3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/commit/0e8802ce6842625845d651456493e7c87625601f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/commit/8c53d0ae52d5ab1e2b37c5abb67def9e7958fd65"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lestrrat-go/jwx/commit/d69a721931a5c48b9850a42404f18e143704adcd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lestrrat-go/jwx"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Parsing JSON serialized payload without protected field can lead to segfault"
}

GHSA-PVGC-VPGW-88MQ

Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31

Details

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

ext4: update orig_path in ext4_find_extent()

In ext4_find_extent(), if the path is not big enough, we free it and set orig_path to NULL. But after reallocating and successfully initializing the path, we don't update orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:

ext4_split_extent path = ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(ppath = NULL) path = ppath; ex = path[depth].p_ext; // NULL pointer dereference!

================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================

Therefore, orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or ppath.

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-49881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: update orig_path in ext4_find_extent()\n\nIn ext4_find_extent(), if the path is not big enough, we free it and set\n*orig_path to NULL. But after reallocating and successfully initializing\nthe path, we don\u0027t update *orig_path, in which case the caller gets a\nvalid path but a NULL ppath, and this may cause a NULL pointer dereference\nor a path memory leak. For example:\n\next4_split_extent\n  path = *ppath = 2000\n  ext4_find_extent\n    if (depth \u003e path[0].p_maxdepth)\n      kfree(path = 2000);\n      *orig_path = path = NULL;\n      path = kcalloc() = 3000\n  ext4_split_extent_at(*ppath = NULL)\n    path = *ppath;\n    ex = path[depth].p_ext;\n    // NULL pointer dereference!\n\n==================================================================\nBUG: kernel NULL pointer dereference, address: 0000000000000010\nCPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847\nRIP: 0010:ext4_split_extent_at+0x6d/0x560\nCall Trace:\n \u003cTASK\u003e\n ext4_split_extent.isra.0+0xcb/0x1b0\n ext4_ext_convert_to_initialized+0x168/0x6c0\n ext4_ext_handle_unwritten_extents+0x325/0x4d0\n ext4_ext_map_blocks+0x520/0xdb0\n ext4_map_blocks+0x2b0/0x690\n ext4_iomap_begin+0x20e/0x2c0\n[...]\n==================================================================\n\nTherefore, *orig_path is updated when the extent lookup succeeds, so that\nthe caller can safely use path or *ppath.",
  "id": "GHSA-pvgc-vpgw-88mq",
  "modified": "2025-11-04T00:31:40Z",
  "published": "2024-10-21T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49881"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/11b230100d6801c014fab2afabc8bdea304c1b96"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5b4b2dcace35f618fe361a87bae6f0d13af31bc1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6766937d0327000ac1b87c97bbecdd28b0dd6599"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6801ed1298204d16a38571091e31178bfdc3c679"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a9fcb1717d75061d3653ed69365c8d45331815cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b63481b3a388ee2df9e295f97273226140422a42"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec0c0beb9b777cdd1edd7df9b36e0f3e67e2bdff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f55ecc58d07a6c1f6d6d5b5af125c25f8da0bda2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-PVHR-37PJ-QC85

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40

Details

Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a NULL Pointer Dereference that leads to a DoS in discoveryd

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-12514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-22T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a NULL Pointer Dereference that leads to a DoS in discoveryd",
  "id": "GHSA-pvhr-37pj-qc85",
  "modified": "2022-05-24T17:40:03Z",
  "published": "2022-05-24T17:40:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12514"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.com/en-us/advisories/vde-2020-038"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PVP4-8Q5G-43FG

Vulnerability from github – Published: 2025-02-21 12:32 – Updated: 2025-03-05 21:32

Details

In Eclipse OMR, from the initial contribution to version 0.4.0, some OMR internal port library and utilities consumers of z/OS atoe functions do not check their return values for NULL memory pointers or for memory allocation failures. This can lead to NULL pointer dereference crashes. Beginning in version 0.5.0, internal OMR consumers of atoe functions handle NULL return values and memory allocation failures correctly.

Severity

5.5 (Medium)


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

5.1 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-1470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-21T10:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In Eclipse OMR, from the initial contribution to version 0.4.0, some OMR internal port library and utilities consumers of z/OS atoe functions do not check their return values for NULL memory pointers or for memory allocation failures.  This can lead to NULL pointer dereference crashes.  Beginning in version 0.5.0, internal OMR consumers of atoe functions handle NULL return values and memory allocation failures correctly.",
  "id": "GHSA-pvp4-8q5g-43fg",
  "modified": "2025-03-05T21:32:05Z",
  "published": "2025-02-21T12:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1470"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-omr/omr/pull/7655"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-omr/omr/pull/7663"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignement/-/issues/54"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

CWE-476

NULL Pointer Dereference

GHSA-PRJQ-F4Q3-FVFR

Impact

Patches

Workarounds

References

GHSA-PRWP-XRV5-5JV3

GHSA-PV35-9GQP-7Q2C

GHSA-PV82-VF69-RQQM

GHSA-PVCC-25WC-FRXR

GHSA-PVCM-VR92-9WX7

GHSA-PVCR-V8J8-J5Q3

Summary

Details

PoC

Impact

GHSA-PVGC-VPGW-88MQ

GHSA-PVHR-37PJ-QC85

GHSA-PVP4-8Q5G-43FG

Mitigation MIT-56

Mitigation

Mitigation

Mitigation

Mitigation