CWE-476
AllowedNULL 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-448C-QHPP-CMMF
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2024-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
xsk: fix usage of multi-buffer BPF helpers for ZC XDP
Currently when packet is shrunk via bpf_xdp_adjust_tail() and memory type is set to MEM_TYPE_XSK_BUFF_POOL, null ptr dereference happens:
[1136314.192256] BUG: kernel NULL pointer dereference, address: 0000000000000034 [1136314.203943] #PF: supervisor read access in kernel mode [1136314.213768] #PF: error_code(0x0000) - not-present page [1136314.223550] PGD 0 P4D 0 [1136314.230684] Oops: 0000 [#1] PREEMPT SMP NOPTI [1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257 [1136314.250469] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210 [1136314.274653] Code: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 00 00 f0 41 ff 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86 [1136314.302907] RSP: 0018:ffffc900089f8db0 EFLAGS: 00010246 [1136314.312967] RAX: ffffc9003168aed0 RBX: ffff8881c3300000 RCX: 0000000000000000 [1136314.324953] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffc9003168c000 [1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09: 0000000000010000 [1136314.348844] R10: ffffc9000e495000 R11: 0000000000000040 R12: 0000000000000001 [1136314.360706] R13: 0000000000000524 R14: ffffc9003168aec0 R15: 0000000000000001 [1136314.373298] FS: 00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000) knlGS:0000000000000000 [1136314.386105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1136314.396532] CR2: 0000000000000034 CR3: 00000001aa912002 CR4: 00000000007706f0 [1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1136314.420173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1136314.431890] PKRU: 55555554 [1136314.439143] Call Trace: [1136314.446058] [1136314.452465] ? __die+0x20/0x70 [1136314.459881] ? page_fault_oops+0x15b/0x440 [1136314.468305] ? exc_page_fault+0x6a/0x150 [1136314.476491] ? asm_exc_page_fault+0x22/0x30 [1136314.484927] ? __xdp_return+0x6c/0x210 [1136314.492863] bpf_xdp_adjust_tail+0x155/0x1d0 [1136314.501269] bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60 [1136314.511263] ice_clean_rx_irq_zc+0x206/0xc60 [ice] [1136314.520222] ? ice_xmit_zc+0x6e/0x150 [ice] [1136314.528506] ice_napi_poll+0x467/0x670 [ice] [1136314.536858] ? ttwu_do_activate.constprop.0+0x8f/0x1a0 [1136314.546010] __napi_poll+0x29/0x1b0 [1136314.553462] net_rx_action+0x133/0x270 [1136314.561619] __do_softirq+0xbe/0x28e [1136314.569303] do_softirq+0x3f/0x60
This comes from __xdp_return() call with xdp_buff argument passed as NULL which is supposed to be consumed by xsk_buff_free() call.
To address this properly, in ZC case, a node that represents the frag being removed has to be pulled out of xskb_list. Introduce appropriate xsk helpers to do such node operation and use them accordingly within bpf_xdp_adjust_tail().
{
"affected": [],
"aliases": [
"CVE-2024-26611"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix usage of multi-buffer BPF helpers for ZC XDP\n\nCurrently when packet is shrunk via bpf_xdp_adjust_tail() and memory\ntype is set to MEM_TYPE_XSK_BUFF_POOL, null ptr dereference happens:\n\n[1136314.192256] BUG: kernel NULL pointer dereference, address:\n0000000000000034\n[1136314.203943] #PF: supervisor read access in kernel mode\n[1136314.213768] #PF: error_code(0x0000) - not-present page\n[1136314.223550] PGD 0 P4D 0\n[1136314.230684] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257\n[1136314.250469] Hardware name: Intel Corporation S2600WFT/S2600WFT,\nBIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210\n[1136314.274653] Code: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 00 00 f0 41 ff 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 \u003cf6\u003e 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86\n[1136314.302907] RSP: 0018:ffffc900089f8db0 EFLAGS: 00010246\n[1136314.312967] RAX: ffffc9003168aed0 RBX: ffff8881c3300000 RCX:\n0000000000000000\n[1136314.324953] RDX: 0000000000000000 RSI: 0000000000000003 RDI:\nffffc9003168c000\n[1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09:\n0000000000010000\n[1136314.348844] R10: ffffc9000e495000 R11: 0000000000000040 R12:\n0000000000000001\n[1136314.360706] R13: 0000000000000524 R14: ffffc9003168aec0 R15:\n0000000000000001\n[1136314.373298] FS: 00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000)\nknlGS:0000000000000000\n[1136314.386105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[1136314.396532] CR2: 0000000000000034 CR3: 00000001aa912002 CR4:\n00000000007706f0\n[1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[1136314.420173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[1136314.431890] PKRU: 55555554\n[1136314.439143] Call Trace:\n[1136314.446058] \u003cIRQ\u003e\n[1136314.452465] ? __die+0x20/0x70\n[1136314.459881] ? page_fault_oops+0x15b/0x440\n[1136314.468305] ? exc_page_fault+0x6a/0x150\n[1136314.476491] ? asm_exc_page_fault+0x22/0x30\n[1136314.484927] ? __xdp_return+0x6c/0x210\n[1136314.492863] bpf_xdp_adjust_tail+0x155/0x1d0\n[1136314.501269] bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60\n[1136314.511263] ice_clean_rx_irq_zc+0x206/0xc60 [ice]\n[1136314.520222] ? ice_xmit_zc+0x6e/0x150 [ice]\n[1136314.528506] ice_napi_poll+0x467/0x670 [ice]\n[1136314.536858] ? ttwu_do_activate.constprop.0+0x8f/0x1a0\n[1136314.546010] __napi_poll+0x29/0x1b0\n[1136314.553462] net_rx_action+0x133/0x270\n[1136314.561619] __do_softirq+0xbe/0x28e\n[1136314.569303] do_softirq+0x3f/0x60\n\nThis comes from __xdp_return() call with xdp_buff argument passed as\nNULL which is supposed to be consumed by xsk_buff_free() call.\n\nTo address this properly, in ZC case, a node that represents the frag\nbeing removed has to be pulled out of xskb_list. Introduce\nappropriate xsk helpers to do such node operation and use them\naccordingly within bpf_xdp_adjust_tail().",
"id": "GHSA-448c-qhpp-cmmf",
"modified": "2024-12-12T18:30:50Z",
"published": "2024-03-11T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26611"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cd781f7216f980207af09c5e0e1bb1eda284540"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82ee4781b8200e44669a354140d5c6bd966b8768"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5114710c8ce86b8317e9b448f4fd15c711c2a82"
}
],
"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-448P-J6V9-GPMW
Vulnerability from github – Published: 2025-08-19 18:31 – Updated: 2025-11-28 15:30In the Linux kernel, the following vulnerability has been resolved:
HID: apple: validate feature-report field count to prevent NULL pointer dereference
A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL pointer dereference whilst the power feature-report is toggled and sent to the device in apple_magic_backlight_report_set(). The power feature-report is expected to have two data fields, but if the descriptor declares one field then accessing field[1] and dereferencing it in apple_magic_backlight_report_set() becomes invalid since field[1] will be NULL.
An example of a minimal descriptor which can cause the crash is something like the following where the report with ID 3 (power report) only references a single 1-byte field. When hid core parses the descriptor it will encounter the final feature tag, allocate a hid_report (all members of field[] will be zeroed out), create field structure and populate it, increasing the maxfield to 1. The subsequent field[1] access and dereference causes the crash.
Usage Page (Vendor Defined 0xFF00) Usage (0x0F) Collection (Application) Report ID (1) Usage (0x01) Logical Minimum (0) Logical Maximum (255) Report Size (8) Report Count (1) Feature (Data,Var,Abs)
Usage (0x02)
Logical Maximum (32767)
Report Size (16)
Report Count (1)
Feature (Data,Var,Abs)
Report ID (3)
Usage (0x03)
Logical Minimum (0)
Logical Maximum (1)
Report Size (8)
Report Count (1)
Feature (Data,Var,Abs)
End Collection
Here we see the KASAN splat when the kernel dereferences the NULL pointer and crashes:
[ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary) [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210 [ 15.165691] Call Trace: [ 15.165691] [ 15.165691] apple_probe+0x571/0xa20 [ 15.165691] hid_device_probe+0x2e2/0x6f0 [ 15.165691] really_probe+0x1ca/0x5c0 [ 15.165691] __driver_probe_device+0x24f/0x310 [ 15.165691] driver_probe_device+0x4a/0xd0 [ 15.165691] __device_attach_driver+0x169/0x220 [ 15.165691] bus_for_each_drv+0x118/0x1b0 [ 15.165691] __device_attach+0x1d5/0x380 [ 15.165691] device_initial_probe+0x12/0x20 [ 15.165691] bus_probe_device+0x13d/0x180 [ 15.165691] device_add+0xd87/0x1510 [...]
To fix this issue we should validate the number of fields that the backlight and power reports have and if they do not have the required number of fields then bail.
{
"affected": [],
"aliases": [
"CVE-2025-38557"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T17:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: apple: validate feature-report field count to prevent NULL pointer dereference\n\nA malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL\npointer dereference whilst the power feature-report is toggled and sent to\nthe device in apple_magic_backlight_report_set(). The power feature-report\nis expected to have two data fields, but if the descriptor declares one\nfield then accessing field[1] and dereferencing it in\napple_magic_backlight_report_set() becomes invalid\nsince field[1] will be NULL.\n\nAn example of a minimal descriptor which can cause the crash is something\nlike the following where the report with ID 3 (power report) only\nreferences a single 1-byte field. When hid core parses the descriptor it\nwill encounter the final feature tag, allocate a hid_report (all members\nof field[] will be zeroed out), create field structure and populate it,\nincreasing the maxfield to 1. The subsequent field[1] access and\ndereference causes the crash.\n\n Usage Page (Vendor Defined 0xFF00)\n Usage (0x0F)\n Collection (Application)\n Report ID (1)\n Usage (0x01)\n Logical Minimum (0)\n Logical Maximum (255)\n Report Size (8)\n Report Count (1)\n Feature (Data,Var,Abs)\n\n Usage (0x02)\n Logical Maximum (32767)\n Report Size (16)\n Report Count (1)\n Feature (Data,Var,Abs)\n\n Report ID (3)\n Usage (0x03)\n Logical Minimum (0)\n Logical Maximum (1)\n Report Size (8)\n Report Count (1)\n Feature (Data,Var,Abs)\n End Collection\n\nHere we see the KASAN splat when the kernel dereferences the\nNULL pointer and crashes:\n\n [ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI\n [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary)\n [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210\n [ 15.165691] Call Trace:\n [ 15.165691] \u003cTASK\u003e\n [ 15.165691] apple_probe+0x571/0xa20\n [ 15.165691] hid_device_probe+0x2e2/0x6f0\n [ 15.165691] really_probe+0x1ca/0x5c0\n [ 15.165691] __driver_probe_device+0x24f/0x310\n [ 15.165691] driver_probe_device+0x4a/0xd0\n [ 15.165691] __device_attach_driver+0x169/0x220\n [ 15.165691] bus_for_each_drv+0x118/0x1b0\n [ 15.165691] __device_attach+0x1d5/0x380\n [ 15.165691] device_initial_probe+0x12/0x20\n [ 15.165691] bus_probe_device+0x13d/0x180\n [ 15.165691] device_add+0xd87/0x1510\n [...]\n\nTo fix this issue we should validate the number of fields that the\nbacklight and power reports have and if they do not have the required\nnumber of fields then bail.",
"id": "GHSA-448p-j6v9-gpmw",
"modified": "2025-11-28T15:30:29Z",
"published": "2025-08-19T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00896c3f41cb6b74fec853386076115ba50baf0a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bb3363da862e0464ec050eea2fb5472a36ad86b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e15d1eaa88179c5185e57a38ab05fe852d0cb8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba08cc6801ec5fb98f2d02b5f0c614c931845325"
}
],
"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-44C5-JQQX-F38C
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-24 21:31In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Check for null before removing sysfs attrs
If coretemp_add_core() gets an error then pdata->core_data[indx] is already NULL and has been kfreed. Don't pass that to sysfs_remove_group() as that will crash in sysfs_remove_group().
[Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Call Trace: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ...
Fix this by checking for NULL first.
{
"affected": [],
"aliases": [
"CVE-2022-49010"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Check for null before removing sysfs attrs\n\nIf coretemp_add_core() gets an error then pdata-\u003ecore_data[indx]\nis already NULL and has been kfreed. Don\u0027t pass that to\nsysfs_remove_group() as that will crash in sysfs_remove_group().\n\n[Shortened for readability]\n[91854.020159] sysfs: cannot create duplicate filename \u0027/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label\u0027\n\u003ccpu offline\u003e\n[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188\n[91855.165103] #PF: supervisor read access in kernel mode\n[91855.194506] #PF: error_code(0x0000) - not-present page\n[91855.224445] PGD 0 P4D 0\n[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI\n...\n[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80\n...\n[91855.796571] Call Trace:\n[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp]\n[91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp]\n[91855.871107] cpuhp_invoke_callback+0x105/0x4b0\n[91855.893432] cpuhp_thread_fun+0x8e/0x150\n...\n\nFix this by checking for NULL first.",
"id": "GHSA-44c5-jqqx-f38c",
"modified": "2024-10-24T21:31:02Z",
"published": "2024-10-21T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89eecabe6a47403237f45aafd7d24f93cb973653"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a89ff5f5cc64b9fe7a992cf56988fd36f56ca82a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae6c8b6e5d5628df1c475c0a8fca1465e205c95b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f06e0cd01eab954bd5f2190c9faa79bb5357e05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb503d077ff7b43913503eaf72995d1239028b99"
}
],
"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-44H7-HPP5-QGHJ
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-24 21:31In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix null-ptr-deref while probe() failed
I got a null-ptr-deref report as following when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0
//probe path: phy_device_register() device_add()
phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called
//remove path: phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-deref
In phy_attach_direct(), after setting the 'dev->driver', probe() fails, device_bind_driver() is not called, so the knode_driver->n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev->driver to NULL in the error path in phy_attach_direct().
{
"affected": [],
"aliases": [
"CVE-2022-49021"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: fix null-ptr-deref while probe() failed\n\nI got a null-ptr-deref report as following when doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nOops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n \u003cTASK\u003e\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x23e/0x2d0\n bus_remove_device+0x1bd/0x240\n device_del+0x357/0x770\n phy_device_remove+0x11/0x30\n mdiobus_unregister+0xa5/0x140\n release_nodes+0x6a/0xa0\n devres_release_all+0xf8/0x150\n device_unbind_cleanup+0x19/0xd0\n\n//probe path:\nphy_device_register()\n device_add()\n\nphy_connect\n phy_attach_direct() //set device driver\n probe() //it\u0027s failed, driver is not bound\n device_bind_driver() // probe failed, it\u0027s not called\n\n//remove path:\nphy_device_remove()\n device_del()\n device_release_driver_internal()\n __device_release_driver() //dev-\u003edrv is not NULL\n klist_remove() \u003c- knode_driver is not added yet, cause null-ptr-deref\n\nIn phy_attach_direct(), after setting the \u0027dev-\u003edriver\u0027, probe() fails,\ndevice_bind_driver() is not called, so the knode_driver-\u003en_klist is not\nset, then it causes null-ptr-deref in __device_release_driver() while\ndeleting device. Fix this by setting dev-\u003edriver to NULL in the error\npath in phy_attach_direct().",
"id": "GHSA-44h7-hpp5-qghj",
"modified": "2024-10-24T21:31:02Z",
"published": "2024-10-21T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49021"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc83226f130c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c"
}
],
"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-44HJ-F354-82Q3
Vulnerability from github – Published: 2022-01-13 00:00 – Updated: 2023-05-27 06:30A Segmentation fault caused by a null pointer dereference vulnerability exists in Gpac through 1.0.1 via the gf_avc_parse_nalu function in av_parsers.c when using mp4box, which causes a denial of service.
{
"affected": [],
"aliases": [
"CVE-2021-40565"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-12T22:15:00Z",
"severity": "MODERATE"
},
"details": "A Segmentation fault caused by a null pointer dereference vulnerability exists in Gpac through 1.0.1 via the gf_avc_parse_nalu function in av_parsers.c when using mp4box, which causes a denial of service.",
"id": "GHSA-44hj-f354-82q3",
"modified": "2023-05-27T06:30:38Z",
"published": "2022-01-13T00:00:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40565"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/issues/1902"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/commit/893fb99b606eebfae46cde151846a980e689039b"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5411"
}
],
"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-44PM-Q7MW-V83G
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-12 18:30In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix NULL pointer dereference when removing device
In suspend and resume cycle, the removal and rescan of device ends up in NULL pointer dereference.
During driver initialization, if the ipc_imem_wwan_channel_init() fails to get the valid device capabilities it returns an error and further no resource (wwan struct) will be allocated. Now in this situation if driver removal procedure is initiated it would result in NULL pointer exception since unallocated wwan struct is dereferenced inside ipc_wwan_deinit().
ipc_imem_run_state_worker() to handle the called functions return value and to release the resource in failure case. It also reports the link down event in failure cases. The user space application can handle this event to do a device reset for restoring the device communication.
{
"affected": [],
"aliases": [
"CVE-2023-53561"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix NULL pointer dereference when removing device\n\nIn suspend and resume cycle, the removal and rescan of device ends\nup in NULL pointer dereference.\n\nDuring driver initialization, if the ipc_imem_wwan_channel_init()\nfails to get the valid device capabilities it returns an error and\nfurther no resource (wwan struct) will be allocated. Now in this\nsituation if driver removal procedure is initiated it would result\nin NULL pointer exception since unallocated wwan struct is dereferenced\ninside ipc_wwan_deinit().\n\nipc_imem_run_state_worker() to handle the called functions return value\nand to release the resource in failure case. It also reports the link\ndown event in failure cases. The user space application can handle this\nevent to do a device reset for restoring the device communication.",
"id": "GHSA-44pm-q7mw-v83g",
"modified": "2026-02-12T18:30:18Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53561"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60829145f1e2650b31ebe6a0ec70a9725b38fa2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/862c6e3e26735247d8a4df41fa2421909c3f4d63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee44bacf462db3ec6e4f0dcfa7931e768670d77c"
}
],
"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-44VJ-X828-CFMJ
Vulnerability from github – Published: 2025-03-11 18:32 – Updated: 2025-03-11 18:32Null pointer dereference in Windows Kernel Memory allows an authorized attacker to deny service locally.
{
"affected": [],
"aliases": [
"CVE-2025-24997"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-11T17:16:37Z",
"severity": "MODERATE"
},
"details": "Null pointer dereference in Windows Kernel Memory allows an authorized attacker to deny service locally.",
"id": "GHSA-44vj-x828-cfmj",
"modified": "2025-03-11T18:32:19Z",
"published": "2025-03-11T18:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24997"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24997"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-44W9-25WR-FJWF
Vulnerability from github – Published: 2024-09-10 12:30 – Updated: 2024-09-10 12:30A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources.
This could allow a remote attacker with elevated privileges to cause a denial of service condition in the system.
{
"affected": [],
"aliases": [
"CVE-2023-30755"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-10T10:15:05Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-7 LTE (All versions \u003c V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions \u003c V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions \u003c V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions \u003c V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources. \n\nThis could allow a remote attacker with elevated privileges to cause a denial of service condition in the system.",
"id": "GHSA-44w9-25wr-fjwf",
"modified": "2024-09-10T12:30:37Z",
"published": "2024-09-10T12:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30755"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-423808.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/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-44WR-9XPQ-76V2
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2024-10-31 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0
At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device.
Now, kexec hands over control to the kdump kernel.
When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables.
iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().
The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember:
1. For the dedicated adapter, kdump kernel would encounter both
default and DDW in FDT. In this case, DDW property is used to
initialize the IOMMU table.
2. A DDW could be direct or dynamic mapped. kdump kernel would
initialize IOMMU table and mark the existing DDW as
"dynamic". This works fine since, at the time of table
initialization, iommu_table_clear() makes some space in the
DDW, for some predefined number of TCEs which are needed for
kdump to succeed.
{
"affected": [],
"aliases": [
"CVE-2024-26745"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on read at 0x00000000\n Faulting instruction address: 0xc000000020847ad4\n Oops: Kernel access of bad area, sig: 11 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)\n MSR: 800000000280b033 \u003cSF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u003e CR: 48288244 XER: 00000008\n CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n ...\n NIP _find_next_zero_bit+0x24/0x110\n LR bitmap_find_next_zero_area_off+0x5c/0xe0\n Call Trace:\n dev_printk_emit+0x38/0x48 (unreliable)\n iommu_area_alloc+0xc4/0x180\n iommu_range_alloc+0x1e8/0x580\n iommu_alloc+0x60/0x130\n iommu_alloc_coherent+0x158/0x2b0\n dma_iommu_alloc_coherent+0x3c/0x50\n dma_alloc_attrs+0x170/0x1f0\n mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n mlx5_function_setup+0xf0/0x510 [mlx5_core]\n mlx5_init_one+0x84/0x210 [mlx5_core]\n probe_one+0x118/0x2c0 [mlx5_core]\n local_pci_probe+0x68/0x110\n pci_call_probe+0x68/0x200\n pci_device_probe+0xbc/0x1a0\n really_probe+0x104/0x540\n __driver_probe_device+0xb4/0x230\n driver_probe_device+0x54/0x130\n __driver_attach+0x158/0x2b0\n bus_for_each_dev+0xa8/0x130\n driver_attach+0x34/0x50\n bus_add_driver+0x16c/0x300\n driver_register+0xa4/0x1b0\n __pci_register_driver+0x68/0x80\n mlx5_init+0xb8/0x100 [mlx5_core]\n do_one_initcall+0x60/0x300\n do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t default and DDW in FDT. In this case, DDW property is used to\n\t initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t initialize IOMMU table and mark the existing DDW as\n\t \"dynamic\". This works fine since, at the time of table\n\t initialization, iommu_table_clear() makes some space in the\n\t DDW, for some predefined number of TCEs which are needed for\n\t kdump to succeed.",
"id": "GHSA-44wr-9xpq-76v2",
"modified": "2024-10-31T21:31:44Z",
"published": "2024-04-04T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26745"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-452G-F7FP-9JF7
Vulnerability from github – Published: 2021-05-21 14:20 – Updated: 2024-10-30 23:13Impact
Calling TF operations with tensors of non-numeric types when the operations expect numeric tensors result in null pointer dereferences.
There are multiple ways to reproduce this, listing a few examples here:
import tensorflow as tf
import numpy as np
data = tf.random.truncated_normal(shape=1,mean=np.float32(20.8739),stddev=779.973,dtype=20,seed=64)
import tensorflow as tf
import numpy as np
data =
tf.random.stateless_truncated_normal(shape=1,seed=[63,70],mean=np.float32(20.8739),stddev=779.973,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.one_hot(indices=[62,50],depth=136,on_value=np.int32(237),off_value=158,axis=856,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.range(start=np.int32(214),limit=660,delta=129,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.raw_ops.ResourceCountUpTo(resource=np.int32(30), limit=872, T=3)
import tensorflow as tf
import numpy as np
writer_array = np.array([1,2],dtype=np.int32)
writer_tensor = tf.convert_to_tensor(writer_array,dtype=tf.resource)
All these examples and similar ones have the same behavior: the conversion from Python array to C++ array is vulnerable to a type confusion:
int pyarray_type = PyArray_TYPE(array);
PyArray_Descr* descr = PyArray_DESCR(array);
switch (pyarray_type) {
...
case NPY_VOID:
// Quantized types are currently represented as custom struct types.
// PyArray_TYPE returns NPY_VOID for structs, and we should look into
// descr to derive the actual type.
// Direct feeds of certain types of ResourceHandles are represented as a
// custom struct type.
return PyArrayDescr_to_TF_DataType(descr, out_tf_datatype);
...
}
For the tensor types involved in the above example, the pyarray_type is NPY_VOID but the descr field is such that descr->field = NULL. Then PyArrayDescr_to_TF_DataType will trigger a null dereference:
Status PyArrayDescr_to_TF_DataType(PyArray_Descr* descr,
TF_DataType* out_tf_datatype) {
PyObject* key;
PyObject* value;
Py_ssize_t pos = 0;
if (PyDict_Next(descr->fields, &pos, &key, &value)) {
...
}
}
This is because the Python's PyDict_Next implementation would dereference the first argument.
Patches
We have patched the issue in GitHub commit 030af767d357d1b4088c4a25c72cb3906abac489.
The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360 as well as Ye Zhang and Yakun Zhang of Baidu X-Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-29513"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-18T23:42:09Z",
"nvd_published_at": "2021-05-14T20:15:00Z",
"severity": "LOW"
},
"details": "### Impact\nCalling TF operations with tensors of non-numeric types when the operations expect numeric tensors result in null pointer dereferences.\n\nThere are multiple ways to reproduce this, listing a few examples here:\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.random.truncated_normal(shape=1,mean=np.float32(20.8739),stddev=779.973,dtype=20,seed=64)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata =\ntf.random.stateless_truncated_normal(shape=1,seed=[63,70],mean=np.float32(20.8739),stddev=779.973,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.one_hot(indices=[62,50],depth=136,on_value=np.int32(237),off_value=158,axis=856,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.range(start=np.int32(214),limit=660,delta=129,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.raw_ops.ResourceCountUpTo(resource=np.int32(30), limit=872, T=3)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\n\nwriter_array = np.array([1,2],dtype=np.int32)\nwriter_tensor = tf.convert_to_tensor(writer_array,dtype=tf.resource)\n```\n\nAll these examples and similar ones have the same behavior: the [conversion from Python array to C++ array](https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L113-L169) is vulnerable to a type confusion:\n\n```cc\n int pyarray_type = PyArray_TYPE(array);\n PyArray_Descr* descr = PyArray_DESCR(array);\n switch (pyarray_type) {\n ...\n case NPY_VOID:\n // Quantized types are currently represented as custom struct types.\n // PyArray_TYPE returns NPY_VOID for structs, and we should look into\n // descr to derive the actual type.\n // Direct feeds of certain types of ResourceHandles are represented as a\n // custom struct type.\n return PyArrayDescr_to_TF_DataType(descr, out_tf_datatype);\n ...\n }\n```\n\nFor the tensor types involved in the above example, the `pyarray_type` is `NPY_VOID` but the `descr` field is such that `descr-\u003efield = NULL`. Then [`PyArrayDescr_to_TF_DataType`](https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L72-L77) will trigger a null dereference:\n\n```cc\nStatus PyArrayDescr_to_TF_DataType(PyArray_Descr* descr,\n TF_DataType* out_tf_datatype) {\n PyObject* key;\n PyObject* value;\n Py_ssize_t pos = 0;\n if (PyDict_Next(descr-\u003efields, \u0026pos, \u0026key, \u0026value)) {\n ...\n }\n}\n```\n\nThis is because the Python\u0027s `PyDict_Next` implementation would dereference the first argument.\n\n### Patches\nWe have patched the issue in GitHub commit [030af767d357d1b4088c4a25c72cb3906abac489](https://github.com/tensorflow/tensorflow/commit/030af767d357d1b4088c4a25c72cb3906abac489).\n\nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360 as well as Ye Zhang and Yakun Zhang of Baidu X-Team.",
"id": "GHSA-452g-f7fp-9jf7",
"modified": "2024-10-30T23:13:43Z",
"published": "2021-05-21T14:20:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-452g-f7fp-9jf7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29513"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/030af767d357d1b4088c4a25c72cb3906abac489"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-441.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-639.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-150.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Type confusion during tensor casts lead to dereferencing null pointers"
}
Mitigation MIT-56
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Mitigation
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Mitigation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
No CAPEC attack patterns related to this CWE.