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.

6372 vulnerabilities reference this CWE, most recent first.

GHSA-PVHR-37PJ-QC85

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

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

Show details on source website

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

GHSA-PVP4-8Q5G-43FG

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

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

Show details on source website

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

GHSA-PW6H-QMVR-5F3P

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-06-29 00:00
VLAI
Details

Mikrotik RouterOs before stable version 6.47 suffers from a memory corruption vulnerability in the /nova/bin/lcdstat process. An authenticated remote attacker can cause a Denial of Service (NULL pointer dereference). NOTE: this is different from CVE-2020-20253 and CVE-2020-20254. All four vulnerabilities in the /nova/bin/lcdstat process are discussed in the CVE-2020-20250 github.com/cq674350529 reference.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-20250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-13T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Mikrotik RouterOs before stable version 6.47 suffers from a memory corruption vulnerability in the /nova/bin/lcdstat process. An authenticated remote attacker can cause a Denial of Service (NULL pointer dereference). NOTE: this is different from CVE-2020-20253 and CVE-2020-20254. All four vulnerabilities in the /nova/bin/lcdstat process are discussed in the CVE-2020-20250 github.com/cq674350529 reference.",
  "id": "GHSA-pw6h-qmvr-5f3p",
  "modified": "2022-06-29T00:00:30Z",
  "published": "2022-05-24T19:07:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cq674350529/pocs_slides/blob/master/advisory/MikroTik/CVE-2020-20250/README.md"
    },
    {
      "type": "WEB",
      "url": "https://mikrotik.com"
    }
  ],
  "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"
    }
  ]
}

GHSA-PWC3-R6H3-WX7V

Vulnerability from github – Published: 2022-05-17 01:19 – Updated: 2022-05-17 01:19
VLAI
Details

Audio in Apple OS X before 10.11.6 allows local users to cause a denial of service (NULL pointer dereference) via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-4649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-07-22T03:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Audio in Apple OS X before 10.11.6 allows local users to cause a denial of service (NULL pointer dereference) via unspecified vectors.",
  "id": "GHSA-pwc3-r6h3-wx7v",
  "modified": "2022-05-17T01:19:49Z",
  "published": "2022-05-17T01:19:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4649"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT206903"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2016/Jul/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/91824"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1036348"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PWG3-M7H4-XJVM

Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 15:30
VLAI
Details

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

reset: uniphier-glue: Fix possible null-ptr-deref

It will cause null-ptr-deref when resource_size(res) invoked, if platform_get_resource() returns NULL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49758"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T17:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nreset: uniphier-glue: Fix possible null-ptr-deref\n\nIt will cause null-ptr-deref when resource_size(res) invoked,\nif platform_get_resource() returns NULL.",
  "id": "GHSA-pwg3-m7h4-xjvm",
  "modified": "2025-04-15T15:30:46Z",
  "published": "2025-03-27T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49758"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a2390c6777e3f6662980c6cfc25cafe9e4fef98"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/633bad3dc81ce2aa561f704ec091e49eb647bd0b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95de286200b2a046da01c4aeba02ae9220d68ca4"
    }
  ],
  "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-PWQF-CGF8-RX4X

Vulnerability from github – Published: 2024-08-28 18:31 – Updated: 2024-08-28 18:31
VLAI
Details

A vulnerability in the DHCPv6 relay agent of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to improper handling of specific fields in a DHCPv6 RELAY-REPLY message. An attacker could exploit this vulnerability by sending a crafted DHCPv6 packet to any IPv6 address that is configured on an affected device. A successful exploit could allow the attacker to cause the dhcp_snoop process to crash and restart multiple times, causing the affected device to reload and resulting in a DoS condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-28T17:15:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the DHCPv6 relay agent of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\nThis vulnerability is due to improper handling of specific fields in a DHCPv6 RELAY-REPLY message. An attacker could exploit this vulnerability by sending a crafted DHCPv6 packet to any IPv6 address that is configured on an affected device. A successful exploit could allow the attacker to cause the dhcp_snoop process to crash and restart multiple times, causing the affected device to reload and resulting in a DoS condition.",
  "id": "GHSA-pwqf-cgf8-rx4x",
  "modified": "2024-08-28T18:31:54Z",
  "published": "2024-08-28T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20446"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-dhcp6-relay-dos-znEAA6xn"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PWRJ-H3FW-3QP7

Vulnerability from github – Published: 2025-07-26 03:30 – Updated: 2025-07-26 03:30
VLAI
Details

A vulnerability was found in D-Link DI-8400 16.07.26A1. It has been classified as problematic. This affects an unknown part of the file usb_paswd.asp of the component jhttpd. The manipulation of the argument share_enable leads to null pointer dereference. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-8175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-404",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-26T03:15:25Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in D-Link DI-8400 16.07.26A1. It has been classified as problematic. This affects an unknown part of the file usb_paswd.asp of the component jhttpd. The manipulation of the argument share_enable leads to null pointer dereference. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-pwrj-h3fw-3qp7",
  "modified": "2025-07-26T03:30:27Z",
  "published": "2025-07-26T03:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8175"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kriswu1337/CVE/blob/main/DI_8400%20Null%20pointer%20dereference%20vulnerability.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.317589"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.317589"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.621708"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com"
    }
  ],
  "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/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PWV6-Q4QX-8VF8

Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-04 21:31
VLAI
Details

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

io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()

Syzkaller produced the below call trace:

BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0 Write of size 8 at addr 0000000000000070 by task repro/16399

CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 Call Trace: dump_stack_lvl+0xcd/0x134 ? io_msg_ring+0x3cb/0x9f0 kasan_report+0xbc/0xf0 ? io_msg_ring+0x3cb/0x9f0 kasan_check_range+0x140/0x190 io_msg_ring+0x3cb/0x9f0 ? io_msg_ring_prep+0x300/0x300 io_issue_sqe+0x698/0xca0 io_submit_sqes+0x92f/0x1c30 __do_sys_io_uring_enter+0xae4/0x24b0 .... RIP: 0033:0x7f2eaf8f8289 RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289 RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004 RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0 R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: panic_on_warn set ...

We don't have a NULL check on file_ptr in io_msg_send_fd() function, so when file_ptr is NUL src_file is also NULL and get_file() dereferences a NULL pointer and leads to above crash.

Add a NULL check to fix this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()\n\nSyzkaller produced the below call trace:\n\n BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0\n Write of size 8 at addr 0000000000000070 by task repro/16399\n\n CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7\n Call Trace:\n  \u003cTASK\u003e\n  dump_stack_lvl+0xcd/0x134\n  ? io_msg_ring+0x3cb/0x9f0\n  kasan_report+0xbc/0xf0\n  ? io_msg_ring+0x3cb/0x9f0\n  kasan_check_range+0x140/0x190\n  io_msg_ring+0x3cb/0x9f0\n  ? io_msg_ring_prep+0x300/0x300\n  io_issue_sqe+0x698/0xca0\n  io_submit_sqes+0x92f/0x1c30\n  __do_sys_io_uring_enter+0xae4/0x24b0\n....\n RIP: 0033:0x7f2eaf8f8289\n RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa\n RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289\n RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004\n RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039\n R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0\n R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000\n  \u003c/TASK\u003e\n Kernel panic - not syncing: panic_on_warn set ...\n\nWe don\u0027t have a NULL check on file_ptr in io_msg_send_fd() function,\nso when file_ptr is NUL src_file is also NULL and get_file()\ndereferences a NULL pointer and leads to above crash.\n\nAdd a NULL check to fix this issue.",
  "id": "GHSA-pwv6-q4qx-8vf8",
  "modified": "2025-12-04T21:31:01Z",
  "published": "2025-09-15T15:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50295"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0163e04ea64cc3dfaa12390286e5f2f481c3b2e3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/16bbdfe5fb0e78e0acb13e45fc127e9a296913f2"
    }
  ],
  "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-PWVW-JX66-55X9

Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2022-05-13 01:02
VLAI
Details

A denial-of-service vulnerability exists in the Pixar Renderman IT Display Service 21.6 (0x69). The vulnerability is present in the parsing of a network packet without proper validation of the packet. The data read-in is not validated, and its use can lead to a null pointer dereference. The IT application is opened by a user and then listens for a connection on port 4001. An attacker can deliver an attack once the application has been opened.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-3841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-26T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "A denial-of-service vulnerability exists in the Pixar Renderman IT Display Service 21.6 (0x69). The vulnerability is present in the parsing of a network packet without proper validation of the packet. The data read-in is not validated, and its use can lead to a null pointer dereference. The IT application is opened by a user and then listens for a connection on port 4001. An attacker can deliver an attack once the application has been opened.",
  "id": "GHSA-pwvw-jx66-55x9",
  "modified": "2022-05-13T01:02:08Z",
  "published": "2022-05-13T01:02:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3841"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0524"
    }
  ],
  "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-PWX6-FVF4-6686

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-15 15:32
VLAI
Details

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

bpf, sockmap: Fix af_unix null-ptr-deref in proto update

unix_stream_connect() sets sk_state (WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)) before it assigns a peer (unix_peer(sk) = newsk). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL.

     CPU0 bpf                            CPU1 connect
     --------                            ------------

                            WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)

sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk

BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Initial idea was to move peer assignment before the sk_state update1, but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered2, but the follow-up discussion3 focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()4. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex5. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock6. This way we circled back to the peer check idea2.

Summary of scenarios where af_unix/stream connect() may race a sockmap update:

  1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()

Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf.

  1. connect() vs BPF program doing update

Update restricted per verifier.c:may_update_sockmap() to

  BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER
  BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)
  BPF_PROG_TYPE_SOCKET_FILTER
  BPF_PROG_TYPE_SCHED_CLS
  BPF_PROG_TYPE_SCHED_ACT
  BPF_PROG_TYPE_XDP
  BPF_PROG_TYPE_SK_REUSEPORT
  BPF_PROG_TYPE_FLOW_DISSECTOR
  BPF_PROG_TYPE_SK_LOOKUP

Plus one more race to consider:

        CPU0 bpf                            CPU1 connect
        --------                            ------------

                               WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)

sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic()

---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53034"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix af_unix null-ptr-deref in proto update\n\nunix_stream_connect() sets sk_state (`WRITE_ONCE(sk-\u003esk_state,\nTCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).\nsk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that\nsocket is properly set up, which would include having a defined peer. IOW,\nthere\u0027s a window when unix_stream_bpf_update_proto() can be called on\nsocket which still has unix_peer(sk) == NULL.\n\n         CPU0 bpf                            CPU1 connect\n         --------                            ------------\n\n                                WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\nsock_map_sk_state_allowed(sk)\n...\nsk_pair = unix_peer(sk)\nsock_hold(sk_pair)\n                                sock_hold(newsk)\n                                smp_mb__after_atomic()\n                                unix_peer(sk) = newsk\n\nBUG: kernel NULL pointer dereference, address: 0000000000000080\nRIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0\nCall Trace:\n  sock_map_link+0x564/0x8b0\n  sock_map_update_common+0x6e/0x340\n  sock_map_update_elem_sys+0x17d/0x240\n  __sys_bpf+0x26db/0x3250\n  __x64_sys_bpf+0x21/0x30\n  do_syscall_64+0x6b/0x3a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInitial idea was to move peer assignment _before_ the sk_state update[1],\nbut that involved an additional memory barrier, and changing the hot path\nwas rejected.\nThen a NULL check during proto update in unix_stream_bpf_update_proto() was\nconsidered[2], but the follow-up discussion[3] focused on the root cause,\ni.e. sockmap update taking a wrong lock. Or, more specifically, missing\nunix_state_lock()[4].\nIn the end it was concluded that teaching sockmap about the af_unix locking\nwould be unnecessarily complex[5].\nComplexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT\nare allowed to update sockmaps, sock_map_update_elem() taking the unix\nlock, as it is currently implemented in unix_state_lock():\nspin_lock(\u0026unix_sk(s)-\u003elock), would be problematic. unix_state_lock() taken\nin a process context, followed by a softirq-context TC BPF program\nattempting to take the same spinlock -- deadlock[6].\nThis way we circled back to the peer check idea[2].\n\n[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/\n[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/\n[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/\n[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/\n[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/\n[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/\n\nSummary of scenarios where af_unix/stream connect() may race a sockmap\nupdate:\n\n1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()\n\n   Implemented NULL check is sufficient. Once assigned, socket peer won\u0027t\n   be released until socket fd is released. And that\u0027s not an issue because\n   sock_map_update_elem_sys() bumps fd refcnf.\n\n2. connect() vs BPF program doing update\n\n   Update restricted per verifier.c:may_update_sockmap() to\n\n      BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER\n      BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)\n      BPF_PROG_TYPE_SOCKET_FILTER\n      BPF_PROG_TYPE_SCHED_CLS\n      BPF_PROG_TYPE_SCHED_ACT\n      BPF_PROG_TYPE_XDP\n      BPF_PROG_TYPE_SK_REUSEPORT\n      BPF_PROG_TYPE_FLOW_DISSECTOR\n      BPF_PROG_TYPE_SK_LOOKUP\n\n   Plus one more race to consider:\n\n            CPU0 bpf                            CPU1 connect\n            --------                            ------------\n\n                                   WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\n   sock_map_sk_state_allowed(sk)\n                                   sock_hold(newsk)\n                                   smp_mb__after_atomic()\n                \n---truncated---",
  "id": "GHSA-pwx6-fvf4-6686",
  "modified": "2026-07-15T15:32:45Z",
  "published": "2026-06-24T18:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53034"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a"
    }
  ],
  "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.