CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6385 vulnerabilities reference this CWE, most recent first.
GHSA-JC37-HHHX-RC2G
Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-29 21:30In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si
syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1].
vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address.
The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes.
Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls.
[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408
{
"affected": [],
"aliases": [
"CVE-2026-53382"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T12:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: fix NULL pointer dereference in vidtv_mux_push_si\n\nsyzbot reported a general protection fault in\nvidtv_psi_ts_psi_write_into [1].\n\nvidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does\nnot check for this before dereferencing the returned pointer to access\nthe continuity counter. This leads to a general protection fault when\naccessing a near-NULL address.\n\nThe root cause is that vidtv_mux_pid_ctx_init() does not check the\nreturn value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs.\nIf the allocation fails, the PID context is never created, but init\nreturns success. The subsequent vidtv_mux_push_si() call then gets\nNULL from vidtv_mux_get_pid_ctx() and crashes.\n\nFix both the root cause (add error check in vidtv_mux_pid_ctx_init\nfor PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for\nall vidtv_mux_get_pid_ctx() calls.\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nWorkqueue: events vidtv_mux_tick\nRIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197\nCall Trace:\n \u003cTASK\u003e\n vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline]\n vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231\n vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196\n vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408",
"id": "GHSA-jc37-hhhx-rc2g",
"modified": "2026-07-29T21:30:53Z",
"published": "2026-07-19T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53382"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/232e4b313ea342672edf8947e067c0de4328405b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/353d9578951dd38bc9679308f5b618ceed1f20fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/455bc12e7b73ab5a2dfcb47822e91e772bc6c42e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6df7e16d4f742c80add58995a6e69385b97aa9e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d8bf3d8f91073f4db347ed3aa6302b56107499c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b28b12be6e8910489e6800ed93ea4d41dfe19683"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd923dadefadb9671b5ac341b672ff424d429c39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0f5a1d7056980a0d512456fdb370cfb72bba86a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f965cf22dda7f512f4922415894c3e528269a4ae"
}
],
"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-JC3Q-V54H-R8HH
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2026-03-25 12:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: drop redundant sched job cleanup when cs is aborted
Once command submission failed due to userptr invalidation in amdgpu_cs_submit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpu_job_free. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457
{
"affected": [],
"aliases": [
"CVE-2023-53228"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: drop redundant sched job cleanup when cs is aborted\n\nOnce command submission failed due to userptr invalidation in\namdgpu_cs_submit, legacy code will perform cleanup of scheduler\njob. However, it\u0027s not needed at all, as former commit has integrated\njob cleanup stuff into amdgpu_job_free. Otherwise, because of double\nfree, a NULL pointer dereference will occur in such scenario.\n\nBug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457",
"id": "GHSA-jc3q-v54h-r8hh",
"modified": "2026-03-25T12:30:18Z",
"published": "2025-09-15T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53228"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1253685f0d3eb3eab0bfc4bf15ab341a5f3da0c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1564d4b105ae535eb3183ecaaa987685b20a888"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdce1644d85e858c68fb5fa67d78eb1035bf34f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec02a29c3c2ef8ad3e15a0e3f96b99a00e5d97b4"
}
],
"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-JCCX-FVX2-CQJJ
Vulnerability from github – Published: 2024-01-03 09:30 – Updated: 2025-11-04 00:30IEEE 1609.2 dissector crash in Wireshark 4.2.0, 4.0.0 to 4.0.11, and 3.6.0 to 3.6.19 allows denial of service via packet injection or crafted capture file
{
"affected": [],
"aliases": [
"CVE-2024-0209"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-03T08:15:10Z",
"severity": "HIGH"
},
"details": "IEEE 1609.2 dissector crash in Wireshark 4.2.0, 4.0.0 to 4.0.11, and 3.6.0 to 3.6.19 allows denial of service via packet injection or crafted capture file",
"id": "GHSA-jccx-fvx2-cqjj",
"modified": "2025-11-04T00:30:42Z",
"published": "2024-01-03T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0209"
},
{
"type": "WEB",
"url": "https://gitlab.com/wireshark/wireshark/-/issues/19501"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00049.html"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2024-02.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JCM6-3979-RVMM
Vulnerability from github – Published: 2022-05-14 03:55 – Updated: 2025-04-20 03:34The bmp_getdata function in libjasper/bmp/bmp_dec.c in JasPer 1.900.5 allows remote attackers to cause a denial of service (NULL pointer dereference) by calling the imginfo command with a crafted BMP image. NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-8690.
{
"affected": [],
"aliases": [
"CVE-2016-8884"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-28T14:59:00Z",
"severity": "MODERATE"
},
"details": "The bmp_getdata function in libjasper/bmp/bmp_dec.c in JasPer 1.900.5 allows remote attackers to cause a denial of service (NULL pointer dereference) by calling the imginfo command with a crafted BMP image. NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-8690.",
"id": "GHSA-jcm6-3979-rvmm",
"modified": "2025-04-20T03:34:57Z",
"published": "2022-05-14T03:55:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8884"
},
{
"type": "WEB",
"url": "https://github.com/mdadams/jasper/commit/5d66894d2313e3f3469f19066e149e08ff076698"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1208"
},
{
"type": "WEB",
"url": "https://blogs.gentoo.org/ago/2016/10/18/jasper-two-null-pointer-dereference-in-bmp_getdata-bmp_dec-c-incomplete-fix-for-cve-2016-8690"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1385499"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/22FCKKHQCQ3S6TZY5G44EFDTMWOJXJRD"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EGI2FZQLOTSZI3VA4ECJERI74SMNQDL4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/22FCKKHQCQ3S6TZY5G44EFDTMWOJXJRD"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EGI2FZQLOTSZI3VA4ECJERI74SMNQDL4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/23/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/23/9"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93834"
}
],
"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-JCMJ-4VM7-4478
Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2025-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: remove oem i2c adapter on finish
Fixes a bug where unbinding of the GPU would leave the oem i2c adapter registered resulting in a null pointer dereference when applications try to access the invalid device.
(cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)
{
"affected": [],
"aliases": [
"CVE-2025-39906"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T08:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: remove oem i2c adapter on finish\n\nFixes a bug where unbinding of the GPU would leave the oem i2c adapter\nregistered resulting in a null pointer dereference when applications try\nto access the invalid device.\n\n(cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)",
"id": "GHSA-jcmj-4vm7-4478",
"modified": "2025-12-12T18:30:28Z",
"published": "2025-10-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39906"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dfd2864a1c4909147663e5a27c055f50f7c2796"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c686124bcf06253620790857ff462f00f3f7a4ab"
}
],
"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-JCX5-2HXR-PWQ4
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int3472: Check for adev == NULL
Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs.
Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().
{
"affected": [],
"aliases": [
"CVE-2024-58011"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: int3472: Check for adev == NULL\n\nNot all devices have an ACPI companion fwnode, so adev might be NULL. This\ncan e.g. (theoretically) happen when a user manually binds one of\nthe int3472 drivers to another i2c/platform device through sysfs.\n\nAdd a check for adev not being set and return -ENODEV in that case to\navoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().",
"id": "GHSA-jcx5-2hxr-pwq4",
"modified": "2026-07-14T15:31:17Z",
"published": "2025-02-27T03:34:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58011"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a30353beca2693d30bde477024d755ffecea514"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46263a0b687a044e645387a9c7692ccd693f09f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f8b210823cc2d1f9d967f089a6c00d025bb237f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a808ecf878ad646ebc9c83d9fc4ce72fd9c49d3d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9c7cc44758f4930b41285a6d54afa8cbd9762b4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JF3W-82F5-FQ58
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-19 18:31In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix invalid derefence of sb_lvbptr
I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example:
[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]---
This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue.
I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour.
{
"affected": [],
"aliases": [
"CVE-2022-50516"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: dlm: fix invalid derefence of sb_lvbptr\n\nI experience issues when putting a lkbsb on the stack and have sb_lvbptr\nfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crash\nwith the following kernel message, the dangled pointer is here\n0xdeadbeef as example:\n\n[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef\n[ 102.749320] #PF: supervisor read access in kernel mode\n[ 102.749323] #PF: error_code(0x0000) - not-present page\n[ 102.749325] PGD 0 P4D 0\n[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565\n[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014\n[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10\n[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 \u003cf3\u003e a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe\n[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202\n[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040\n[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070\n[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001\n[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70\n[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001\n[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000\n[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0\n[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 102.749379] PKRU: 55555554\n[ 102.749381] Call Trace:\n[ 102.749382] \u003cTASK\u003e\n[ 102.749383] ? send_args+0xb2/0xd0\n[ 102.749389] send_common+0xb7/0xd0\n[ 102.749395] _unlock_lock+0x2c/0x90\n[ 102.749400] unlock_lock.isra.56+0x62/0xa0\n[ 102.749405] dlm_unlock+0x21e/0x330\n[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture]\n[ 102.749419] ? preempt_count_sub+0xba/0x100\n[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture]\n[ 102.786186] kthread+0x10a/0x130\n[ 102.786581] ? kthread_complete_and_exit+0x20/0x20\n[ 102.787156] ret_from_fork+0x22/0x30\n[ 102.787588] \u003c/TASK\u003e\n[ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw\n[ 102.792536] CR2: 00000000deadbeef\n[ 102.792930] ---[ end trace 0000000000000000 ]---\n\nThis patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags\nis set when copying the lvbptr array instead of if it\u0027s just null which\nfixes for me the issue.\n\nI think this patch can fix other dlm users as well, depending how they\nhandle the init, freeing memory handling of sb_lvbptr and don\u0027t set\nDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a\nhidden issue all the time. However with checking on DLM_LKF_VALBLK the\nuser always need to provide a sb_lvbptr non-null value. There might be\nmore intelligent handling between per ls lvblen, DLM_LKF_VALBLK and\nnon-null to report the user the way how DLM API is used is wrong but can\nbe added for later, this will only fix the current behaviour.",
"id": "GHSA-jf3w-82f5-fq58",
"modified": "2026-02-19T18:31:42Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ab6d3030652b5de0015176a5b0ad9df9b847514"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57c1cfb5781068e5d3632bc6e5f74a8fcc4f1a30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7175e131ebba47afef47e6ac4d5bab474d1e6e49"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea7be82fd7e1f5de72208bce93fbbe6de6c13dec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef3033b435a6bac547166b793025578fab2f9df3"
}
],
"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-JF6C-W73V-473W
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-25 18:30In the Linux kernel, the following vulnerability has been resolved:
can: slcan: fix freed work crash
The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)
Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed.
So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances.
The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()?
I see the same pattern in can327. So it perhaps needs the very same fix.
{
"affected": [],
"aliases": [
"CVE-2022-48984"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: slcan: fix freed work crash\n\nThe LTP test pty03 is causing a crash in slcan:\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014\n Workqueue: 0x0 (events)\n RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)\n Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 \u003c49\u003e 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e\n RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968\n RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0\n RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734\n R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000\n R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0\n FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0\n Call Trace:\n \u003cTASK\u003e\n worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436)\n kthread (/home/rich/kernel/linux/kernel/kthread.c:376)\n ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)\n\nApparently, the slcan\u0027s tx_work is freed while being scheduled. While\nslcan_netdev_close() (netdev side) calls flush_work(\u0026sl-\u003etx_work),\nslcan_close() (tty side) does not. So when the netdev is never set UP,\nbut the tty is stuffed with bytes and forced to wakeup write, the work\nis scheduled, but never flushed.\n\nSo add an additional flush_work() to slcan_close() to be sure the work\nis flushed under all circumstances.\n\nThe Fixes commit below moved flush_work() from slcan_close() to\nslcan_netdev_close(). What was the rationale behind it? Maybe we can\ndrop the one in slcan_netdev_close()?\n\nI see the same pattern in can327. So it perhaps needs the very same fix.",
"id": "GHSA-jf6c-w73v-473w",
"modified": "2024-10-25T18:30:47Z",
"published": "2024-10-21T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48984"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb"
}
],
"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-JF88-W289-CR26
Vulnerability from github – Published: 2025-08-19 18:31 – Updated: 2026-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Check governor before using governor->name
Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name.
{
"affected": [],
"aliases": [
"CVE-2025-38609"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T17:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Check governor before using governor-\u003ename\n\nCommit 96ffcdf239de (\"PM / devfreq: Remove redundant governor_name from\nstruct devfreq\") removes governor_name and uses governor-\u003ename to replace\nit. But devfreq-\u003egovernor may be NULL and directly using\ndevfreq-\u003egovernor-\u003ename may cause null pointer exception. Move the check of\ngovernor to before using governor-\u003ename.",
"id": "GHSA-jf88-w289-cr26",
"modified": "2026-01-07T18:30:19Z",
"published": "2025-08-19T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38609"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2731c68f536fddcb71332db7f8d78c5eb4684c04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/631e101728df2a86b8fb761b49fad9712c651f8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75323a49aa603cf5484a6d74d0d329e86d756e11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81f50619370045120c133bfdda5b320c8c97d41e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bab7834c03820eb11269bc48f07c3800192460d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5632359dbc44862fc1ed04093c1f57529830261"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0479e878d4beb45e73c03e574c59f0a23ccd176"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JF99-2H2P-Q9X7
Vulnerability from github – Published: 2022-05-17 00:22 – Updated: 2022-05-17 00:22The EBML_FindNextElement function in ebmlmain.c in libebml2 through 2012-08-26 allows remote attackers to cause a denial of service (Null pointer dereference and application crash) via a crafted mkv file.
{
"affected": [],
"aliases": [
"CVE-2017-12800"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-10T02:29:00Z",
"severity": "MODERATE"
},
"details": "The EBML_FindNextElement function in ebmlmain.c in libebml2 through 2012-08-26 allows remote attackers to cause a denial of service (Null pointer dereference and application crash) via a crafted mkv file.",
"id": "GHSA-jf99-2h2p-q9x7",
"modified": "2022-05-17T00:22:00Z",
"published": "2022-05-17T00:22:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12800"
},
{
"type": "WEB",
"url": "https://github.com/Matroska-Org/foundation-source/issues/24"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/144902/mkvalidator-0.5.1-Denial-Of-Service.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/Nov/19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.