Common Weakness Enumeration

CWE-476

Allowed

NULL Pointer Dereference

Abstraction: Base · Status: Stable

The product dereferences a pointer that it expects to be valid but is NULL.

6310 vulnerabilities reference this CWE, most recent first.

GHSA-VR5F-5953-GFJ5

Vulnerability from github – Published: 2024-04-28 15:30 – Updated: 2025-09-18 15:30
VLAI
Details

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

net/sched: taprio: avoid disabling offload when it was never enabled

In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()).

The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()).

But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).

But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags.

As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled.

The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc:

$ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c

Fix this by keeping track of the operations we made, and undo the offload only if we actually did it.

I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below:

$ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; / 0 8 / struct Qdisc * root; / 8 8 / u32 flags; / 16 4 / enum tk_offsets tk_offset; / 20 4 / int clockid; / 24 4 / bool offloaded; / 28 1 /

    /* XXX 3 bytes hole, try to pack */

    atomic64_t                 picos_per_byte;       /*    32     0 */

    /* XXX 8 bytes hole, try to pack */

    spinlock_t                 current_entry_lock;   /*    40     0 */

    /* XXX 8 bytes hole, try to pack */

    struct sched_entry *       current_entry;        /*    48     8 */
    struct sched_gate_list *   oper_sched;           /*    56     8 */
    /* --- cacheline 1 boundary (64 bytes) --- */
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-28T13:15:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: taprio: avoid disabling offload when it was never enabled\n\nIn an incredibly strange API design decision, qdisc-\u003edestroy() gets\ncalled even if qdisc-\u003einit() never succeeded, not exclusively since\ncommit 87b60cfacf9f (\"net_sched: fix error recovery at qdisc creation\"),\nbut apparently also earlier (in the case of qdisc_create_dflt()).\n\nThe taprio qdisc does not fully acknowledge this when it attempts full\noffload, because it starts off with q-\u003eflags = TAPRIO_FLAGS_INVALID in\ntaprio_init(), then it replaces q-\u003eflags with TCA_TAPRIO_ATTR_FLAGS\nparsed from netlink (in taprio_change(), tail called from taprio_init()).\n\nBut in taprio_destroy(), we call taprio_disable_offload(), and this\ndetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q-\u003eflags).\n\nBut looking at the implementation of FULL_OFFLOAD_IS_ENABLED()\n(a bitwise check of bit 1 in q-\u003eflags), it is invalid to call this macro\non q-\u003eflags when it contains TAPRIO_FLAGS_INVALID, because that is set\nto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on\nan invalid set of flags.\n\nAs a result, it is possible to crash the kernel if user space forces an\nerror between setting q-\u003eflags = TAPRIO_FLAGS_INVALID, and the calling\nof taprio_enable_offload(). This is because drivers do not expect the\noffload to be disabled when it was never enabled.\n\nThe error that we force here is to attach taprio as a non-root qdisc,\nbut instead as child of an mqprio root qdisc:\n\n$ tc qdisc add dev swp0 root handle 1: \\\n\tmqprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0\n$ tc qdisc replace dev swp0 parent 1:1 \\\n\ttaprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 990000 sched-entry S 0x80 100000 \\\n\tflags 0x0 clockid CLOCK_TAI\nUnable to handle kernel paging request at virtual address fffffffffffffff8\n[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 96000004 [#1] PREEMPT SMP\nCall trace:\n taprio_dump+0x27c/0x310\n vsc9959_port_setup_tc+0x1f4/0x460\n felix_port_setup_tc+0x24/0x3c\n dsa_slave_setup_tc+0x54/0x27c\n taprio_disable_offload.isra.0+0x58/0xe0\n taprio_destroy+0x80/0x104\n qdisc_create+0x240/0x470\n tc_modify_qdisc+0x1fc/0x6b0\n rtnetlink_rcv_msg+0x12c/0x390\n netlink_rcv_skb+0x5c/0x130\n rtnetlink_rcv+0x1c/0x2c\n\nFix this by keeping track of the operations we made, and undo the\noffload only if we actually did it.\n\nI\u0027ve added \"bool offloaded\" inside a 4 byte hole between \"int clockid\"\nand \"atomic64_t picos_per_byte\". Now the first cache line looks like\nbelow:\n\n$ pahole -C taprio_sched net/sched/sch_taprio.o\nstruct taprio_sched {\n        struct Qdisc * *           qdiscs;               /*     0     8 */\n        struct Qdisc *             root;                 /*     8     8 */\n        u32                        flags;                /*    16     4 */\n        enum tk_offsets            tk_offset;            /*    20     4 */\n        int                        clockid;              /*    24     4 */\n        bool                       offloaded;            /*    28     1 */\n\n        /* XXX 3 bytes hole, try to pack */\n\n        atomic64_t                 picos_per_byte;       /*    32     0 */\n\n        /* XXX 8 bytes hole, try to pack */\n\n        spinlock_t                 current_entry_lock;   /*    40     0 */\n\n        /* XXX 8 bytes hole, try to pack */\n\n        struct sched_entry *       current_entry;        /*    48     8 */\n        struct sched_gate_list *   oper_sched;           /*    56     8 */\n        /* --- cacheline 1 boundary (64 bytes) --- */",
  "id": "GHSA-vr5f-5953-gfj5",
  "modified": "2025-09-18T15:30:21Z",
  "published": "2024-04-28T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48644"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd"
    }
  ],
  "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-VR5F-V75P-G4QW

Vulnerability from github – Published: 2024-03-25 09:32 – Updated: 2024-11-07 18:31
VLAI
Details

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

iommu/amd: Clear DMA ops when switching domain

Since commit 08a27c1c3ecf ("iommu: Add support to change default domain of an iommu group") a user can switch a device between IOMMU and direct DMA through sysfs. This doesn't work for AMD IOMMU at the moment because dev->dma_ops is not cleared when switching from a DMA to an identity IOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an identity domain, causing an oops:

# echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/unbind # echo identity > /sys/bus/pci/devices/0000:00:05.0/iommu_group/type # echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/bind ... BUG: kernel NULL pointer dereference, address: 0000000000000028 ... Call Trace: iommu_dma_alloc e1000e_setup_tx_resources e1000e_open

Since iommu_change_dev_def_domain() calls probe_finalize() again, clear the dma_ops there like Vt-d does.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47140"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-25T09:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Clear DMA ops when switching domain\n\nSince commit 08a27c1c3ecf (\"iommu: Add support to change default domain\nof an iommu group\") a user can switch a device between IOMMU and direct\nDMA through sysfs. This doesn\u0027t work for AMD IOMMU at the moment because\ndev-\u003edma_ops is not cleared when switching from a DMA to an identity\nIOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an\nidentity domain, causing an oops:\n\n  # echo 0000:00:05.0 \u003e /sys/sys/bus/pci/drivers/e1000e/unbind\n  # echo identity \u003e /sys/bus/pci/devices/0000:00:05.0/iommu_group/type\n  # echo 0000:00:05.0 \u003e /sys/sys/bus/pci/drivers/e1000e/bind\n   ...\n  BUG: kernel NULL pointer dereference, address: 0000000000000028\n   ...\n   Call Trace:\n    iommu_dma_alloc\n    e1000e_setup_tx_resources\n    e1000e_open\n\nSince iommu_change_dev_def_domain() calls probe_finalize() again, clear\nthe dma_ops there like Vt-d does.",
  "id": "GHSA-vr5f-v75p-g4qw",
  "modified": "2024-11-07T18:31:20Z",
  "published": "2024-03-25T09:32:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47140"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d6177a6556f853785867e2ec6d5b7f4906f0d809"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3f2cf46291a693eab21adb94171b0128c2a9ec1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VR9F-9RG5-QV8M

Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30
VLAI
Details

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

scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID

An error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to lpfc_nlp_put() with a null pointer to a nodelist structure.

Changed lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon entry.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T12:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID\n\nAn error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to\nlpfc_nlp_put() with a null pointer to a nodelist structure.\n\nChanged lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon\nentry.",
  "id": "GHSA-vr9f-9rg5-qv8m",
  "modified": "2026-01-16T21:30:29Z",
  "published": "2025-10-01T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50467"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/04e7cd8c85636a329d1a6e5a269a7c8b6f71c41c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/59b7e210a522b836a01516c71ee85d1d92c1f075"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82dc1fe4324e2c897f2ed1c66f4fcff03094ac3a"
    }
  ],
  "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-VRF6-366F-P2HR

Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-11-03 21:33
VLAI
Details

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

clk: qcom: dispcc-sm6350: Add missing parent_map for a clock

If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following:

[ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c

Add the parent_map property for the clock where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-58080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-06T17:15:21Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: dispcc-sm6350: Add missing parent_map for a clock\n\nIf a clk_rcg2 has a parent, it should also have parent_map defined,\notherwise we\u0027ll get a NULL pointer dereference when calling clk_set_rate\nlike the following:\n\n  [    3.388105] Call trace:\n  [    3.390664]  qcom_find_src_index+0x3c/0x70 (P)\n  [    3.395301]  qcom_find_src_index+0x1c/0x70 (L)\n  [    3.399934]  _freq_tbl_determine_rate+0x48/0x100\n  [    3.404753]  clk_rcg2_determine_rate+0x1c/0x28\n  [    3.409387]  clk_core_determine_round_nolock+0x58/0xe4\n  [    3.421414]  clk_core_round_rate_nolock+0x48/0xfc\n  [    3.432974]  clk_core_round_rate_nolock+0xd0/0xfc\n  [    3.444483]  clk_core_set_rate_nolock+0x8c/0x300\n  [    3.455886]  clk_set_rate+0x38/0x14c\n\nAdd the parent_map property for the clock where it\u0027s missing and also\nun-inline the parent_data as well to keep the matching parent_map and\nparent_data together.",
  "id": "GHSA-vrf6-366f-p2hr",
  "modified": "2025-11-03T21:33:08Z",
  "published": "2025-03-06T18:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58080"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2dba8d5d423fa5f6f3a687aa6e0da5808f69091b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ad28517385e2821e8e43388d6a0b3e1ba0bc3ab"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3daca9050857220726732ad9d4a8512069386f46"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1f15808adfd77268eac7fefce5378ad9fedbfba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4cdb196f182d2fbe336c968228be00d8c3fed05"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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-VRH2-53XM-76HQ

Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2024-10-22 18:32
VLAI
Details

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

media: mediatek: vcodec: Fix H264 stateless decoder smatch warning

Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T13:15:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix H264 stateless decoder smatch warning\n\nFix a smatch static checker warning on vdec_h264_req_if.c.\nWhich leads to a kernel crash when fb is NULL.",
  "id": "GHSA-vrh2-53xm-76hq",
  "modified": "2024-10-22T18:32:10Z",
  "published": "2024-10-21T15:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47752"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/18181b0c1c5bd43846e5e0ae3d61a4a1adceab03"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7878d3a385efab560dce793b595447867fb163f2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/790d1848fac5ac3b1c474f66162598ab07a20c21"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c6b9f971b43980de8893610f606d751131fb5d86"
    }
  ],
  "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-VRH7-X64V-7VXQ

Vulnerability from github – Published: 2023-02-08 22:21 – Updated: 2025-11-04 22:08
VLAI
Summary
openssl-src contains `NULL` dereference during PKCS7 data verification
Details

A NULL pointer can be dereferenced when signatures are being verified on PKCS7 signed or signedAndEnveloped data. In case the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available the digest initialization will fail. There is a missing check for the return value from the initialization function which later leads to invalid usage of the digest API most likely leading to a crash. The unavailability of an algorithm can be caused by using FIPS enabled configuration of providers or more commonly by not loading the legacy provider.

PKCS7 data is processed by the SMIME library calls and also by the time stamp (TS) library calls. The TLS implementation in OpenSSL does not call these functions however third party applications would be affected if they call these functions to verify signatures on untrusted data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "openssl-src"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "300.0.0"
            },
            {
              "fixed": "300.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0401"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T22:21:22Z",
    "nvd_published_at": "2023-02-08T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A `NULL` pointer can be dereferenced when signatures are being verified on PKCS7 `signed` or `signedAndEnveloped` data. In case the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available the digest initialization will fail. There is a missing check for the return value from the initialization function which later leads to invalid usage of the digest API most likely leading to a crash. The unavailability of an algorithm can be caused by using FIPS enabled configuration of providers or more commonly by not loading the legacy provider.\n\nPKCS7 data is processed by the SMIME library calls and also by the time stamp (TS) library calls. The TLS implementation in OpenSSL does not call these functions however third party applications would be affected if they call these functions to verify signatures on untrusted data.",
  "id": "GHSA-vrh7-x64v-7vxq",
  "modified": "2025-11-04T22:08:55Z",
  "published": "2023-02-08T22:21:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0401"
    },
    {
      "type": "WEB",
      "url": "https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d3b6dfd70db844c4499bec6ad6601623a565e674"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/alexcrichton/openssl-src-rs"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2023-0003"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0013.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202402-08"
    },
    {
      "type": "WEB",
      "url": "https://www.openssl.org/news/secadv/20230207.txt"
    }
  ],
  "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": "openssl-src contains `NULL` dereference during PKCS7 data verification"
}

GHSA-VRM9-VQV5-39GR

Vulnerability from github – Published: 2022-05-03 03:16 – Updated: 2022-05-03 03:16
VLAI
Details

The get_server_hello function in the SSLv2 client code in OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows remote servers to cause a denial of service (client crash) via unknown vectors that trigger a null pointer dereference.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2006-4343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-09-28T18:07:00Z",
    "severity": "MODERATE"
  },
  "details": "The get_server_hello function in the SSLv2 client code in OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows remote servers to cause a denial of service (client crash) via unknown vectors that trigger a null pointer dereference.",
  "id": "GHSA-vrm9-vqv5-39gr",
  "modified": "2022-05-03T03:16:26Z",
  "published": "2022-05-03T03:16:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-4343"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29240"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10207"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A4356"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/4773"
    },
    {
      "type": "WEB",
      "url": "https://www2.itrc.hp.com/service/cki/docDisplay.do?docId=c00967144"
    },
    {
      "type": "WEB",
      "url": "http://docs.info.apple.com/article.html?artnum=304829"
    },
    {
      "type": "WEB",
      "url": "http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01118771"
    },
    {
      "type": "WEB",
      "url": "http://issues.rpath.com/browse/RPL-613"
    },
    {
      "type": "WEB",
      "url": "http://itrc.hp.com/service/cki/docDisplay.do?docId=c00805100"
    },
    {
      "type": "WEB",
      "url": "http://itrc.hp.com/service/cki/docDisplay.do?docId=c00849540"
    },
    {
      "type": "WEB",
      "url": "http://kolab.org/security/kolab-vendor-notice-11.txt"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2006/Nov/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/049715.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.vmware.com/pipermail/security-announce/2008/000008.html"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=130497311408250\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://openbsd.org/errata.html#openssl2"
    },
    {
      "type": "WEB",
      "url": "http://openvpn.net/changelog.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22094"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22116"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22130"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22165"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22166"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22172"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22186"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22193"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22207"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22212"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22216"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22220"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22240"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22259"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22260"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22284"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22298"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22330"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22385"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22460"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22487"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22500"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22544"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22626"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22758"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22772"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22791"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22799"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23038"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23155"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23280"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23309"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23340"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23680"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23794"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23915"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/24950"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/25420"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/25889"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/26329"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30124"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/31492"
    },
    {
      "type": "WEB",
      "url": "http://security.freebsd.org/advisories/FreeBSD-SA-06:23.openssl.asc"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200610-11.xml"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1016943"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1017522"
    },
    {
      "type": "WEB",
      "url": "http://slackware.com/security/viewer.php?l=slackware-security\u0026y=2006\u0026m=slackware-security.676946"
    },
    {
      "type": "WEB",
      "url": "http://sourceforge.net/project/shownotes.php?release_id=461863\u0026group_id=69227"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-102668-1"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-102711-1"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-201531-1"
    },
    {
      "type": "WEB",
      "url": "http://support.avaya.com/elmodocs2/security/ASA-2006-220.htm"
    },
    {
      "type": "WEB",
      "url": "http://support.avaya.com/elmodocs2/security/ASA-2006-260.htm"
    },
    {
      "type": "WEB",
      "url": "http://www.cisco.com/en/US/products/hw/contnetw/ps4162/tsd_products_security_response09186a008077af1b.html"
    },
    {
      "type": "WEB",
      "url": "http://www.cisco.com/warp/public/707/cisco-sr-20061108-openssl.shtml"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2006/dsa-1185"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2006/dsa-1195"
    },
    {
      "type": "WEB",
      "url": "http://www.gentoo.org/security/en/glsa/glsa-200612-11.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.ingate.com/relnote-452.php"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/386964"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2006:172"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2006:177"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2006:178"
    },
    {
      "type": "WEB",
      "url": "http://www.novell.com/linux/security/advisories/2006_24_sr.html"
    },
    {
      "type": "WEB",
      "url": "http://www.novell.com/linux/security/advisories/2006_58_openssl.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.021-openssl.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openssl.org/news/secadv_20060928.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpujan2007-101493.html"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/29263"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2006-0695.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2008-0629.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/447318/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/447393/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/456546/100/200/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/489739/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/20246"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/22083"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28276"
    },
    {
      "type": "WEB",
      "url": "http://www.serv-u.com/releasenotes"
    },
    {
      "type": "WEB",
      "url": "http://www.trustix.org/errata/2006/0054"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-353-1"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA06-333A.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2008-0005.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/ace2/doc/releasenotes_ace2.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/esx2/doc/esx-202-200612-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/esx21/doc/esx-213-200612-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/esx25/doc/esx-253-200612-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/esx25/doc/esx-254-200612-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/player/doc/releasenotes_player.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/player2/doc/releasenotes_player2.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/server/doc/releasenotes_server.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/vi3/doc/esx-3069097-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/vi3/doc/esx-9986131-patch.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/ws55/doc/releasenotes_ws55.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/support/ws6/doc/releasenotes_ws6.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/3820"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/3860"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/3869"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/3902"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/3936"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4036"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4264"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4401"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4417"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4443"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4750"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/0343"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/1401"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/1973"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/2783"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/0905/references"
    },
    {
      "type": "WEB",
      "url": "http://www.xerox.com/downloads/usa/en/c/cert_ESSNetwork_XRX07001_v1.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VRMW-4324-6MFP

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-01-06 21:30
VLAI
Details

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

f2fs: split initial and dynamic conditions for extent_cache

Let's allocate the extent_cache tree without dynamic conditions to avoid a missing condition causing a panic as below.

# create a file w/ a compressed flag # disable the compression # panic while updating extent_cache

F2FS-fs (dm-64): Swapfile: last extent is not aligned to section F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Adding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 Write of size 4 at addr 0000000000000030 by task syz-executor154/3327

CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1 Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023 Call Trace: __dump_stack out/common/lib/dump_stack.c:77 [inline] dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118 __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415 kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428 kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186 __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37 instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155 f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172 f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline] f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764 vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310 ksys_fallocate out/common/fs/open.c:333 [inline] __do_sys_fallocate out/common/fs/open.c:341 [inline] __se_sys_fallocate out/common/fs/open.c:339 [inline] __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339 do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52770"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: split initial and dynamic conditions for extent_cache\n\nLet\u0027s allocate the extent_cache tree without dynamic conditions to avoid a\nmissing condition causing a panic as below.\n\n # create a file w/ a compressed flag\n # disable the compression\n # panic while updating extent_cache\n\nF2FS-fs (dm-64): Swapfile: last extent is not aligned to section\nF2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N)\nAdding 124996k swap on ./swap-file.  Priority:0 extents:2 across:17179494468k\n==================================================================\nBUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]\nBUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]\nBUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]\nBUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]\nBUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295\nWrite of size 4 at addr 0000000000000030 by task syz-executor154/3327\n\nCPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G           O      5.10.185 #1\nHardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023\nCall Trace:\n __dump_stack out/common/lib/dump_stack.c:77 [inline]\n dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118\n __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415\n kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428\n kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186\n __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37\n instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]\n atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]\n queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]\n __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]\n _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295\n __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155\n f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172\n f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline]\n f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764\n vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310\n ksys_fallocate out/common/fs/open.c:333 [inline]\n __do_sys_fallocate out/common/fs/open.c:341 [inline]\n __se_sys_fallocate out/common/fs/open.c:339 [inline]\n __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339\n do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46",
  "id": "GHSA-vrmw-4324-6mfp",
  "modified": "2025-01-06T21:30:49Z",
  "published": "2024-05-21T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52770"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9de787139b0258a5dd1f498780c26d76b61d2958"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d83309e7e006cee8afca83523559017c824fbf7a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f803982190f0265fd36cf84670aa6daefc2b0768"
    }
  ],
  "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-VRQ5-53CV-FF3X

Vulnerability from github – Published: 2023-04-14 12:30 – Updated: 2024-04-04 03:27
VLAI
Details

Cesanta MJS v2.20.0 was discovered to contain a SEGV vulnerability via ffi_cb_impl_wpwwwww at src/mjs_ffi.c. This vulnerability can lead to a Denial of Service (DoS).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-29569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-14T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Cesanta MJS v2.20.0 was discovered to contain a SEGV vulnerability via ffi_cb_impl_wpwwwww at src/mjs_ffi.c. This vulnerability can lead to a Denial of Service (DoS).",
  "id": "GHSA-vrq5-53cv-ff3x",
  "modified": "2024-04-04T03:27:52Z",
  "published": "2023-04-14T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29569"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cesanta/mjs/issues/239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/z1r00/fuzz_vuln/blob/main/mjs/SEGV/mjs_ffi/readme.md"
    }
  ],
  "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-VRX4-X92W-9VHV

Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2026-05-12 15:30
VLAI
Details

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

sctp: sysctl: auth_enable: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

  • Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

  • current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-19T11:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: auth_enable: avoid using current-\u003ensproxy\n\nAs mentioned in a previous commit of this series, using the \u0027net\u0027\nstructure via \u0027current\u0027 is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0027s/writer\u0027s netns vs only\n  from the opener\u0027s netns.\n\n- current-\u003ensproxy can be NULL in some cases, resulting in an \u0027Oops\u0027\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0027net\u0027 structure can be obtained from the table-\u003edata using\ncontainer_of().\n\nNote that table-\u003edata could also be used directly, but that would\nincrease the size of this fix, while \u0027sctp.ctl_sock\u0027 still needs to be\nretrieved from \u0027net\u0027 structure.",
  "id": "GHSA-vrx4-x92w-9vhv",
  "modified": "2026-05-12T15:30:43Z",
  "published": "2025-01-19T12:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21638"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10c869a52f266e40f548cc3c565d14930a5edafc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15649fd5415eda664ef35780c2013adeb5d9c695"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b67030d39f2b00f94ac1f0af11ba6657589e4d3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ec30c54f339c640aa7e49d7e9f7bbed6bd42bf6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd2a2939423566c654545fa3e96a656662a0af9e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c184bc621e3cef03ac9ba81a50dda2dae6a21d36"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cf387cdebfaebae228dfba162f94c567a67610c3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dc583e7e5f8515ca489c0df28e4362a70eade382"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/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"
    }
  ]
}

Mitigation MIT-56
Implementation

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
Requirements

Select a programming language that is not susceptible to these issues.

Mitigation
Implementation

Check the results of all functions that return a value and verify that the value is non-null before acting upon it.

Mitigation
Architecture and Design

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
Implementation

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.