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-R3R8-3HXX-X882
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: only release the dirty pages io tree after successful writes
[WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time:
BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs] Call Trace: close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] generic_shutdown_super+0x89/0x1a0 kill_anon_super+0x16/0x40 btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivate_locked_super+0x2d/0xb0 cleanup_mnt+0xdc/0x140 task_work_run+0x5a/0xa0 exit_to_user_mode_loop+0x123/0x4b0 do_syscall_64+0x243/0x7c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7
I'm using a stripped down version, which seems to trigger the warning more reliably:
_fsstress_pid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clear_warn_once mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & _fsstress_pid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $_fsstress_pid unset _fsstress_pid umount $mnt
if dmesg | grep -q "WARNING"; then
fail
fi
}
for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done
[CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish.
After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree.
However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted.
Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-53284"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: only release the dirty pages io tree after successful writes\n\n[WARNING]\nWith extra warning on dirty extent buffers at umount (aka, the next\npatch in the series), test case generic/388 can trigger the following\nwarning about dirty extent buffers at unmount time:\n\n BTRFS critical (device dm-2 state E): emergency shutdown\n BTRFS error (device dm-2 state E): error while writing out transaction: -30\n BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.\n BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)\n BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem\n BTRFS info (device dm-2 state EA): forced readonly\n BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c\n ------------[ cut here ]------------\n WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368\n CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]\n Call Trace:\n \u003cTASK\u003e\n close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n generic_shutdown_super+0x89/0x1a0\n kill_anon_super+0x16/0x40\n btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n deactivate_locked_super+0x2d/0xb0\n cleanup_mnt+0xdc/0x140\n task_work_run+0x5a/0xa0\n exit_to_user_mode_loop+0x123/0x4b0\n do_syscall_64+0x243/0x7c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7\n BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7\n\nI\u0027m using a stripped down version, which seems to trigger the warning\nmore reliably:\n\n _fsstress_pid=\"\"\n workload()\n {\n \tdmesg -C\n \tmkfs.btrfs -f -K $dev \u003e /dev/null\n \techo 1 \u003e /sys/kernel/debug/clear_warn_once\n \tmount $dev $mnt\n \t$fsstress -w -n 1024 -p 4 -d $mnt \u0026\n \t_fsstress_pid=$!\n \tsleep 0\n \t$godown $mnt\n \tpkill --echo -PIPE fsstress \u003e /dev/null\n \twait $_fsstress_pid\n \tunset _fsstress_pid\n \tumount $mnt\n\n \tif dmesg | grep -q \"WARNING\"; then\n \t\tfail\n \tfi\n }\n\n for (( i = 0; i \u003c $runtime; i++ )); do\n \techo \"=== $i/$runtime ===\"\n \tworkload\n done\n\n[CAUSE]\nInside btrfs_write_and_wait_transaction(), we first try to write all\ndirty ebs, then wait for them to finish.\n\nAfter that we call btrfs_extent_io_tree_release() to free all\nextent states from dirty_pages io tree.\n\nHowever if we hit an error from btrfs_write_marked_extent(), then we\nstill call btrfs_extent_io_tree_release() to clear that dirty_pages io\ntree, which may contain dirty records that we haven\u0027t yet submitted.\n\nFurthermore, the later transaction cleanup path will utilize that\ndirty_pages io tree to properly cleanup those dirty ebs, but since it\u0027s\nalready empty, no dirty ebs are properly cleaned up, thus will later\ntrigger the warnings inside invalidate_btree_folios().\n---truncated---",
"id": "GHSA-r3r8-3hxx-x882",
"modified": "2026-06-28T09:31:48Z",
"published": "2026-06-26T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53284"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4066c55e109475a06d18a1f127c939d551211956"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ebb7eba1237dc198768b9c76506a79f924c82bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df03d67dc63722845cb9fe59d815d1225b04fd54"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3WM-5QJQ-C8QP
Vulnerability from github – Published: 2025-10-04 09:30 – Updated: 2026-01-27 21:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Harden uplink netdev access against device unbind
The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic.
BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.
{
"affected": [],
"aliases": [
"CVE-2025-39947"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T08:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Harden uplink netdev access against device unbind\n\nThe function mlx5_uplink_netdev_get() gets the uplink netdevice\npointer from mdev-\u003emlx5e_res.uplink_netdev. However, the netdevice can\nbe removed and its pointer cleared when unbound from the mlx5_core.eth\ndriver. This results in a NULL pointer, causing a kernel panic.\n\n BUG: unable to handle page fault for address: 0000000000001300\n at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]\n Call Trace:\n \u003cTASK\u003e\n mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]\n esw_offloads_enable+0x593/0x910 [mlx5_core]\n mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]\n mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]\n devlink_nl_eswitch_set_doit+0x60/0xd0\n genl_family_rcv_msg_doit+0xe0/0x130\n genl_rcv_msg+0x183/0x290\n netlink_rcv_skb+0x4b/0xf0\n genl_rcv+0x24/0x40\n netlink_unicast+0x255/0x380\n netlink_sendmsg+0x1f3/0x420\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x119/0x180\n do_syscall_64+0x53/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEnsure the pointer is valid before use by checking it for NULL. If it\nis valid, immediately call netdev_hold() to take a reference, and\npreventing the netdevice from being freed while it is in use.",
"id": "GHSA-r3wm-5qjq-c8qp",
"modified": "2026-01-27T21:31:35Z",
"published": "2025-10-04T09:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cb17c88edd3a1c7aa6bc880dcdb35a6866fcb2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b4be64fd9fec16418f365c2d8e47a7566e9eba5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8df354eb2dd63d111ed5ae2e956e0dbb22bcf93b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1f3db4e7a3be29fc17f01850f162363f919370d"
}
],
"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-R428-MJ5M-MQVQ
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-11-04 18:31In the Linux kernel, the following vulnerability has been resolved:
drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init
devm_kasprintf() calls can return null pointers on failure. But some return values were not checked in zynqmp_audio_init().
Add NULL check in zynqmp_audio_init(), avoid referencing null pointers in the subsequent code.
{
"affected": [],
"aliases": [
"CVE-2025-22099"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init\n\ndevm_kasprintf() calls can return null pointers on failure.\nBut some return values were not checked in zynqmp_audio_init().\n\nAdd NULL check in zynqmp_audio_init(), avoid referencing null\npointers in the subsequent code.",
"id": "GHSA-r428-mj5m-mqvq",
"modified": "2025-11-04T18:31:31Z",
"published": "2025-04-16T15:34:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22099"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/066d6f22e7d84953db6bbf2dae507401157660c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0660f9c588a1246a1a543c91a1e3cad910237da"
}
],
"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-R435-G2MC-22V9
Vulnerability from github – Published: 2022-05-14 02:18 – Updated: 2022-05-14 02:18jsish version 2.4.67 contains a CWE-476: NULL Pointer Dereference vulnerability in Jsi_LogMsg (jsiUtils.c:196) that can result in Crash due to segmentation fault. This attack appear to be exploitable via the victim executing specially crafted javascript code. This vulnerability appears to have been fixed in 2.4.69.
{
"affected": [],
"aliases": [
"CVE-2018-1000661"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-06T17:29:00Z",
"severity": "MODERATE"
},
"details": "jsish version 2.4.67 contains a CWE-476: NULL Pointer Dereference vulnerability in Jsi_LogMsg (jsiUtils.c:196) that can result in Crash due to segmentation fault. This attack appear to be exploitable via the victim executing specially crafted javascript code. This vulnerability appears to have been fixed in 2.4.69.",
"id": "GHSA-r435-g2mc-22v9",
"modified": "2022-05-14T02:18:54Z",
"published": "2022-05-14T02:18:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000661"
},
{
"type": "WEB",
"url": "https://jsish.org/fossil/jsi/tktview/2adeb066894695b38309d92771aea11c8e0a56a8"
}
],
"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"
}
]
}
GHSA-R486-9X35-XF6G
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38JasPer before version 2.0.10 is vulnerable to a null pointer dereference was found in the decoded creation of JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash.
{
"affected": [],
"aliases": [
"CVE-2016-9600"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-12T15:29:00Z",
"severity": "MODERATE"
},
"details": "JasPer before version 2.0.10 is vulnerable to a null pointer dereference was found in the decoded creation of JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash.",
"id": "GHSA-r486-9x35-xf6g",
"modified": "2022-05-13T01:38:28Z",
"published": "2022-05-13T01:38:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9600"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1208"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1410026"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3693-1"
}
],
"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"
}
]
}
GHSA-R4C5-Q57V-M6CJ
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-06 15:30In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl.
Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt().
The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up.
This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*].
[*] Is this a bug in aesni-intel_glue.c?
The s390x oops looks something like:
Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE. AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]
{
"affected": [],
"aliases": [
"CVE-2023-53599"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix missing initialisation affecting gcm-aes-s390\n\nFix af_alg_alloc_areq() to initialise areq-\u003efirst_rsgl.sgl.sgt.sgl to point\nto the scatterlist array in areq-\u003efirst_rsgl.sgl.sgl.\n\nWithout this, the gcm-aes-s390 driver will oops when it tries to do\ngcm_walk_start() on req-\u003edst because req-\u003edst is set to the value of\nareq-\u003efirst_rsgl.sgl.sgl by _aead_recvmsg() calling\naead_request_set_crypt().\n\nThe problem comes if an empty ciphertext is passed: the loop in\naf_alg_get_rsgl() just passes straight out and doesn\u0027t set areq-\u003efirst_rsgl\nup.\n\nThis isn\u0027t a problem on x86_64 using gcmaes_crypt_by_sg() because, as far\nas I can tell, that ignores req-\u003edst and only uses req-\u003esrc[*].\n\n[*] Is this a bug in aesni-intel_glue.c?\n\nThe s390x oops looks something like:\n\n Unable to handle kernel pointer dereference in virtual kernel address space\n Failing address: 0000000a00000000 TEID: 0000000a00000803\n Fault in home space mode while using kernel ASCE.\n AS:00000000a43a0007 R3:0000000000000024\n Oops: 003b ilc:2 [#1] SMP\n ...\n Call Trace:\n [\u003c000003ff7fc3d47e\u003e] gcm_walk_start+0x16/0x28 [aes_s390]\n [\u003c00000000a2a342f2\u003e] crypto_aead_decrypt+0x9a/0xb8\n [\u003c00000000a2a60888\u003e] aead_recvmsg+0x478/0x698\n [\u003c00000000a2e519a0\u003e] sock_recvmsg+0x70/0xb0\n [\u003c00000000a2e51a56\u003e] sock_read_iter+0x76/0xa0\n [\u003c00000000a273e066\u003e] vfs_read+0x26e/0x2a8\n [\u003c00000000a273e8c4\u003e] ksys_read+0xbc/0x100\n [\u003c00000000a311d808\u003e] __do_syscall+0x1d0/0x1f8\n [\u003c00000000a312ff30\u003e] system_call+0x70/0x98\n Last Breaking-Event-Address:\n [\u003c000003ff7fc3e6b4\u003e] gcm_aes_crypt+0x104/0xa68 [aes_s390]",
"id": "GHSA-r4c5-q57v-m6cj",
"modified": "2026-02-06T15:30:58Z",
"published": "2025-10-04T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53599"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c9d205040d7c0eaccc473917f9b0bb0a923e440"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a4b8aa0a916b39a39175584c07222434fa6c6ef"
}
],
"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-R4CP-JGM6-J6M3
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-03-06 12:30In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.
{
"affected": [],
"aliases": [
"CVE-2024-58012"
],
"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\nASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params\n\nEach cpu DAI should associate with a widget. However, the topology might\nnot create the right number of DAI widgets for aggregated amps. And it\nwill cause NULL pointer deference.\nCheck that the DAI widget associated with the CPU DAI is valid to prevent\nNULL pointer deference due to missing DAI widgets in topologies with\naggregated amps.",
"id": "GHSA-r4cp-jgm6-j6m3",
"modified": "2025-03-06T12:30:41Z",
"published": "2025-02-27T03:34:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/569922b82ca660f8b24e705f6cf674e6b1f99cc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/789a2fbf0900982788408d3b0034e0e3f914fb3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e012a77e4d7632cf615ba9625b1600ed8985c3b5"
}
],
"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-R4G5-X2H5-R8GG
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-11-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ASoC: kirkwood: Fix potential NULL dereference
In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if CONFIG_PLAT_ORION macro is not defined. Fix this bug by adding NULL check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
{
"affected": [],
"aliases": [
"CVE-2024-38550"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: kirkwood: Fix potential NULL dereference\n\nIn kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if\nCONFIG_PLAT_ORION macro is not defined.\nFix this bug by adding NULL check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.",
"id": "GHSA-r4g5-x2h5-r8gg",
"modified": "2024-11-01T18:31:26Z",
"published": "2024-06-19T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38550"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50"
}
],
"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-R4MQ-HVHP-3H35
Vulnerability from github – Published: 2025-06-30 09:30 – Updated: 2025-11-19 15:31In the Linux kernel, the following vulnerability has been resolved:
sunrpc: handle SVC_GARBAGE during svc auth processing as auth error
tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there.
If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble.
The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR.
Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash.
{
"affected": [],
"aliases": [
"CVE-2025-38089"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-30T08:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: handle SVC_GARBAGE during svc auth processing as auth error\n\ntianshuo han reported a remotely-triggerable crash if the client sends a\nkernel RPC server a specially crafted packet. If decoding the RPC reply\nfails in such a way that SVC_GARBAGE is returned without setting the\nrq_accept_statp pointer, then that pointer can be dereferenced and a\nvalue stored there.\n\nIf it\u0027s the first time the thread has processed an RPC, then that\npointer will be set to NULL and the kernel will crash. In other cases,\nit could create a memory scribble.\n\nThe server sunrpc code treats a SVC_GARBAGE return from svc_authenticate\nor pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531\nsays that if authentication fails that the RPC should be rejected\ninstead with a status of AUTH_ERR.\n\nHandle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of\nAUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This\nsidesteps the whole problem of touching the rpc_accept_statp pointer in\nthis situation and avoids the crash.",
"id": "GHSA-r4mq-hvhp-3h35",
"modified": "2025-11-19T15:31:32Z",
"published": "2025-06-30T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38089"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/353e75b55e583635bf71cde6abcec274dba05edd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/599c489eea793821232a2f69a00fa57d82b0ac98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94d10a4dba0bc482f2b01e39f06d5513d0f75742"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c90459cd58bb421d275337093d8e901e0ba748dd"
},
{
"type": "WEB",
"url": "https://github.com/keymaker-arch/NFSundown"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2025/07/02/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/07/02/2"
}
],
"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-R4R3-CH7M-8PH9
Vulnerability from github – Published: 2025-08-29 18:30 – Updated: 2025-09-22 18:30A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.
We have already fixed the vulnerability in the following versions: QTS 5.2.5.3145 build 20250526 and later QuTS hero h5.2.5.3138 build 20250519 and later
{
"affected": [],
"aliases": [
"CVE-2025-29882"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-29T18:15:35Z",
"severity": "MODERATE"
},
"details": "A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.2.5.3145 build 20250526 and later\nQuTS hero h5.2.5.3138 build 20250519 and later",
"id": "GHSA-r4r3-ch7m-8ph9",
"modified": "2025-09-22T18:30:30Z",
"published": "2025-08-29T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29882"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-25-21"
}
],
"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: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"
}
]
}
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.