CWE-129
AllowedImproper Validation of Array Index
Abstraction: Variant · Status: Draft
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
781 vulnerabilities reference this CWE, most recent first.
GHSA-23V5-VGF6-5452
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-07 03:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: ctxfi: Fix missing SPDIFI1 index handling
SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.
{
"affected": [],
"aliases": [
"CVE-2026-31776"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Fix missing SPDIFI1 index handling\n\nSPDIF1 DAIO type isn\u0027t properly handled in daio_device_index() for\nhw20k2, and it returned -EINVAL, which ended up with the out-of-bounds\narray access. Follow the hw20k1 pattern and return the proper index\nfor this type, too.",
"id": "GHSA-23v5-vgf6-5452",
"modified": "2026-05-07T03:31:20Z",
"published": "2026-05-01T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31776"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/28222e13666b5d26bf66563c056069ed32f87b33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57698f184e1afbe054b3cd30e2c43a67c11d7f5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b39985303a639b159dea306a032c08ef22f029d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/950decf59d4e978b60a792ce0b3e1555a608f489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0b45bdfffce9894b39392d061c14fda24de8b67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3b0e5f84058a9c3d0542a71c2b3a7801e4ee26a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b045ab3dff97edae6d538eeff900a34c098761f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8859675f1cf92fe2eb25ef525440702140a0b55"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-249X-RQHX-JGFC
Vulnerability from github – Published: 2022-05-14 03:30 – Updated: 2022-05-14 03:30In all Qualcomm products with Android releases from CAF using the Linux kernel, an array index out of bounds vulnerability exists in LPP.
{
"affected": [],
"aliases": [
"CVE-2016-10386"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-18T18:29:00Z",
"severity": "CRITICAL"
},
"details": "In all Qualcomm products with Android releases from CAF using the Linux kernel, an array index out of bounds vulnerability exists in LPP.",
"id": "GHSA-249x-rqhx-jgfc",
"modified": "2022-05-14T03:30:41Z",
"published": "2022-05-14T03:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10386"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-07-01"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-04-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103671"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-24R2-2RF2-WHFQ
Vulnerability from github – Published: 2025-05-06 09:31 – Updated: 2025-05-06 09:31Memory corruption while acquire and update IOCTLs during IFE output resource ID validation.
{
"affected": [],
"aliases": [
"CVE-2024-45578"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-06T09:15:20Z",
"severity": "HIGH"
},
"details": "Memory corruption while acquire and update IOCTLs during IFE output resource ID validation.",
"id": "GHSA-24r2-2rf2-whfq",
"modified": "2025-05-06T09:31:33Z",
"published": "2025-05-06T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45578"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/may-2025-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-255R-96JC-W7R6
Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30DVP80ES300T with Improper Validation of Array Index Vulnerability
{
"affected": [],
"aliases": [
"CVE-2026-14193"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T07:16:22Z",
"severity": "HIGH"
},
"details": "DVP80ES300T with Improper Validation of Array Index Vulnerability",
"id": "GHSA-255r-96jc-w7r6",
"modified": "2026-07-01T09:30:25Z",
"published": "2026-07-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14193"
},
{
"type": "WEB",
"url": "https://filecenter.deltaww.com/news/download/doc/Delta-PCSA-2026-00013_DVP80ES300T%20Improper%20Validation%20of%20Array%20Index%20Vulnerability%20(CVE-2026-14193).pdf"
}
],
"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-257P-5VV9-2JFF
Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_sedge() seh->next().
{
"affected": [],
"aliases": [
"CVE-2020-28634"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_sedge() seh-\u003enext().",
"id": "GHSA-257p-5vv9-2jff",
"modified": "2022-04-24T00:00:29Z",
"published": "2022-04-19T00:00:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28634"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-34"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-25PF-CRF2-9CQG
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-02-27 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr
[Why] There is a potential memory access violation while iterating through array of dcn35 clks.
[How] Limit iteration per array size.
{
"affected": [],
"aliases": [
"CVE-2024-26699"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:52Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr\n\n[Why]\nThere is a potential memory access violation while\niterating through array of dcn35 clks.\n\n[How]\nLimit iteration per array size.",
"id": "GHSA-25pf-crf2-9cqg",
"modified": "2025-02-27T15:31:49Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26699"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-25PP-PJQX-3F66
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: don't allow 1 packet limit
The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well.
This fixes the following syzkaller reported crash:
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270
The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1):
tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1
Scenario that triggers the crash:
-
the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1
-
TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.
-
the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.
At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access.
{
"affected": [],
"aliases": [
"CVE-2024-57996"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T02:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: don\u0027t allow 1 packet limit\n\nThe current implementation does not work correctly with a limit of\n1. iproute2 actually checks for this and this patch adds the check in\nkernel as well.\n\nThis fixes the following syzkaller reported crash:\n\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6\nindex 65535 is out of range for type \u0027struct sfq_head[128]\u0027\nCPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x125/0x19f lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:148 [inline]\n __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347\n sfq_link net/sched/sch_sfq.c:210 [inline]\n sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238\n sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500\n sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525\n qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319\n qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296\n netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]\n dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362\n __dev_close_many+0x214/0x350 net/core/dev.c:1468\n dev_close_many+0x207/0x510 net/core/dev.c:1506\n unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738\n unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695\n unregister_netdevice include/linux/netdevice.h:2893 [inline]\n __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689\n tun_detach drivers/net/tun.c:705 [inline]\n tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640\n __fput+0x203/0x840 fs/file_table.c:280\n task_work_run+0x129/0x1b0 kernel/task_work.c:185\n exit_task_work include/linux/task_work.h:33 [inline]\n do_exit+0x5ce/0x2200 kernel/exit.c:931\n do_group_exit+0x144/0x310 kernel/exit.c:1046\n __do_sys_exit_group kernel/exit.c:1057 [inline]\n __se_sys_exit_group kernel/exit.c:1055 [inline]\n __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055\n do_syscall_64+0x6c/0xd0\n entry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fe5e7b52479\nCode: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.\nRSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000\nRBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0\nR13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270\n\nThe crash can be also be reproduced with the following (with a tc\nrecompiled to allow for sfq limits of 1):\n\ntc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s\n../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1\nifconfig dummy0 up\nping -I dummy0 -f -c2 -W0.1 8.8.8.8\nsleep 1\n\nScenario that triggers the crash:\n\n* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1\n\n* TBF dequeues: it peeks from SFQ which moves the packet to the\n gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so\n it schedules itself for later.\n\n* the second packet is sent and TBF tries to queues it to SFQ. qdisc\n qlen is now 2 and because the SFQ limit is 1 the packet is dropped\n by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,\n however q-\u003etail is not NULL.\n\nAt this point, assuming no more packets are queued, when sch_dequeue\nruns again it will decrement the qlen for the current empty slot\ncausing an underflow and the subsequent out of bounds access.",
"id": "GHSA-25pp-pjqx-3f66",
"modified": "2026-05-12T15:30:46Z",
"published": "2025-02-27T03:34:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57996"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10685681bafce6febb39770f3387621bf5d67d0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b562b7f9231432da40d12e19786c1bd7df653a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e6d9d87626cf89eeffb4d943db12cb5b10bf961"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35d0137305ae2f97260a9047f445bd4434bd6cc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d8947f2153ee9c5ab4cb17861a11cc45f30e8c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fefc294204f10a3405f175f4ac2be16d63f135e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/833e9a1c27b82024db7ff5038a51651f48f05e5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e12f6013d0a69660e8b99bfe381b9546ae667328"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-2645-7HQP-7QR7
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-25 21:31In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Bounds check struct nfc_target arrays
While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:
memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)
This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.
{
"affected": [],
"aliases": [
"CVE-2022-48967"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:08Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFC: nci: Bounds check struct nfc_target arrays\n\nWhile running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:\n\n memcpy: detected field-spanning write (size 129) of single field \"target-\u003esensf_res\" at net/nfc/nci/ntf.c:260 (size 18)\n\nThis appears to be a legitimate lack of bounds checking in\nnci_add_new_protocol(). Add the missing checks.",
"id": "GHSA-2645-7hqp-7qr7",
"modified": "2024-10-25T21:31:27Z",
"published": "2024-10-21T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48967"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-26GQ-P25F-99CP
Vulnerability from github – Published: 2026-07-24 21:48 – Updated: 2026-08-13 17:35Summary
An integer-overflow vulnerability in the frp server's optional SSH Tunnel Gateway lets any unauthenticated remote attacker crash the entire frps process with a single five-byte message. When the gateway parses an SSH exec channel request in pkg/ssh/server.go, it adds a small constant to a four-byte length value taken directly from the request. Because that length is fully attacker-controlled, a value of 0xFFFFFFFF makes the addition wrap around to a tiny number, defeating the only bounds check and forcing an out-of-range slice. Go raises a panic that nothing recovers, so the whole server exits. In the default gateway mode SSH clients are not authenticated and the request is handled before any frp token is checked, so the crash is reachable pre-authentication. It carries no state and is trivially repeatable, turning one crash into a sustained outage that drops every tunnel for every user.
Details
The exec request payload is a four-byte big-endian length followed by that many command bytes, and the length field is fully attacker-controlled. The gateway computes the end of the command as 4 + length. The constant 4 takes the uint32 type of the length field, so 4 + 0xFFFFFFFF wraps modulo 2^32 to 3. The only guard compares the real payload size against this wrapped value, so a five-byte payload passes the test 5 < 3, and the slice runs from index 4 to index 3:
// pkg/ssh/server.go:315-319
end := 4 + binary.BigEndian.Uint32(req.Payload[:4]) // 4 + 0xFFFFFFFF wraps to 3
if len(req.Payload) < int(end) { // 5 < 3 is false, so it passes
continue
}
extraPayload := string(req.Payload[4:end]) // payload[4:3] -> panic
The handler runs in a bare goroutine and no function in the call chain installs a recover, so the panic unwinds to the top of the goroutine and terminates the whole process rather than the single connection:
// pkg/ssh/server.go:226
go s.handleNewChannel(newChannel, extraPayloadCh) // no recover anywhere in the chain
The sink is reachable without credentials in the default configuration. When no authorized-keys file is set, the gateway disables SSH client authentication, which is the default and documented mode where users authenticate through the frp token embedded in the SSH command. The exec request is processed during the channel phase, before that token is validated, so an unauthenticated peer reaches the sink:
// pkg/ssh/gateway.go:74
sshConfig.NoClientAuth = cfg.AuthorizedKeysFile == "" // default: no client auth
Affected product: frp (fatedier), frps server, SSH Tunnel Gateway
Affected versions: v0.53.0 (when the gateway was introduced) through v0.70.0, confirmed against a v0.70.0 build
PoC
The SSH Tunnel Gateway must be enabled with no authorized-keys file, which is the default mode of any deployment that turns the gateway on. No credentials and no knowledge of the target are required.
Enable the gateway on a stock v0.70.0 build:
bindPort = 7000
[sshTunnelGateway]
bindPort = 2200
As an unauthenticated SSH client, open a session channel and send one exec request whose four-byte length prefix is 0xFFFFFFFF followed by a single byte, giving the five-byte payload ff ff ff ff 41. The server immediately panics and exits:
panic: runtime error: slice bounds out of range [4:3]
...github.com/fatedier/frp/pkg/ssh.(*TunnelServer).handleNewChannel
.../frp/pkg/ssh/server.go:319
The shell prompt returns in the server terminal, confirming the whole process has terminated and every other client tunnel is dropped at the same instant. A well-formed request of the same length (prefix 1) leaves the server running, proving the crash is caused by the overflow value and not by the exec request itself. The attacker can re-send the payload after any restart to hold the server down indefinitely.
Impact
This is an unauthenticated remote denial of service (CWE-190) leading to an out-of-range array index (CWE-129) and an unhandled process crash (CWE-755). A single five-byte, credential-free message kills the entire frps process. Because one frps commonly multiplexes the tunnels of many clients, the crash drops every active tunnel for every tenant at once and new logins are refused until the process is restarted, and re-sending the payload after each restart keeps the service down indefinitely (CWE-400). There is no confidentiality or integrity impact and no code execution.
This issue only affects frps instances with the SSH tunnel gateway explicitly enabled. The SSH tunnel gateway is disabled by default and is not commonly used in typical frps deployments. Default frps configurations are not affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.70.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/fatedier/frp"
},
"ranges": [
{
"events": [
{
"introduced": "0.53.0"
},
{
"fixed": "0.70.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73564"
],
"database_specific": {
"cwe_ids": [
"CWE-129",
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:48:04Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nAn integer-overflow vulnerability in the frp server\u0027s optional SSH Tunnel Gateway lets any unauthenticated remote attacker crash the entire `frps` process with a single five-byte message. When the gateway parses an SSH `exec` channel request in `pkg/ssh/server.go`, it adds a small constant to a four-byte length value taken directly from the request. Because that length is fully attacker-controlled, a value of `0xFFFFFFFF` makes the addition wrap around to a tiny number, defeating the only bounds check and forcing an out-of-range slice. Go raises a panic that nothing recovers, so the whole server exits. In the default gateway mode SSH clients are not authenticated and the request is handled before any frp token is checked, so the crash is reachable pre-authentication. It carries no state and is trivially repeatable, turning one crash into a sustained outage that drops every tunnel for every user.\n\n## Details\n\nThe `exec` request payload is a four-byte big-endian length followed by that many command bytes, and the length field is fully attacker-controlled. The gateway computes the end of the command as `4 + length`. The constant `4` takes the `uint32` type of the length field, so `4 + 0xFFFFFFFF` wraps modulo 2^32 to `3`. The only guard compares the real payload size against this wrapped value, so a five-byte payload passes the test `5 \u003c 3`, and the slice runs from index 4 to index 3:\n\n```go\n// pkg/ssh/server.go:315-319\nend := 4 + binary.BigEndian.Uint32(req.Payload[:4]) // 4 + 0xFFFFFFFF wraps to 3\nif len(req.Payload) \u003c int(end) { // 5 \u003c 3 is false, so it passes\n continue\n}\nextraPayload := string(req.Payload[4:end]) // payload[4:3] -\u003e panic\n```\n\nThe handler runs in a bare goroutine and no function in the call chain installs a `recover`, so the panic unwinds to the top of the goroutine and terminates the whole process rather than the single connection:\n\n```go\n// pkg/ssh/server.go:226\ngo s.handleNewChannel(newChannel, extraPayloadCh) // no recover anywhere in the chain\n```\n\nThe sink is reachable without credentials in the default configuration. When no authorized-keys file is set, the gateway disables SSH client authentication, which is the default and documented mode where users authenticate through the frp token embedded in the SSH command. The `exec` request is processed during the channel phase, before that token is validated, so an unauthenticated peer reaches the sink:\n\n```go\n// pkg/ssh/gateway.go:74\nsshConfig.NoClientAuth = cfg.AuthorizedKeysFile == \"\" // default: no client auth\n```\n\nAffected product: frp (fatedier), `frps` server, SSH Tunnel Gateway\nAffected versions: v0.53.0 (when the gateway was introduced) through v0.70.0, confirmed against a v0.70.0 build\n\n## PoC\n\nThe SSH Tunnel Gateway must be enabled with no authorized-keys file, which is the default mode of any deployment that turns the gateway on. No credentials and no knowledge of the target are required.\n\nEnable the gateway on a stock v0.70.0 build:\n\n```toml\nbindPort = 7000\n\n[sshTunnelGateway]\nbindPort = 2200\n```\n\nAs an unauthenticated SSH client, open a session channel and send one `exec` request whose four-byte length prefix is `0xFFFFFFFF` followed by a single byte, giving the five-byte payload `ff ff ff ff 41`. The server immediately panics and exits:\n\n```text\npanic: runtime error: slice bounds out of range [4:3]\n...github.com/fatedier/frp/pkg/ssh.(*TunnelServer).handleNewChannel\n .../frp/pkg/ssh/server.go:319\n```\n\nThe shell prompt returns in the server terminal, confirming the whole process has terminated and every other client tunnel is dropped at the same instant. A well-formed request of the same length (prefix `1`) leaves the server running, proving the crash is caused by the overflow value and not by the `exec` request itself. The attacker can re-send the payload after any restart to hold the server down indefinitely.\n\n## Impact\n\nThis is an unauthenticated remote denial of service (CWE-190) leading to an out-of-range array index (CWE-129) and an unhandled process crash (CWE-755). A single five-byte, credential-free message kills the entire `frps` process. Because one `frps` commonly multiplexes the tunnels of many clients, the crash drops every active tunnel for every tenant at once and new logins are refused until the process is restarted, and re-sending the payload after each restart keeps the service down indefinitely (CWE-400). There is no confidentiality or integrity impact and no code execution.\n\nThis issue only affects frps instances with the SSH tunnel gateway explicitly enabled. The SSH tunnel gateway is disabled by default and is not commonly used in typical frps deployments. Default frps configurations are not affected.",
"id": "GHSA-26gq-p25f-99cp",
"modified": "2026-08-13T17:35:53Z",
"published": "2026-07-24T21:48:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fatedier/frp/security/advisories/GHSA-26gq-p25f-99cp"
},
{
"type": "WEB",
"url": "https://github.com/fatedier/frp/pull/5428"
},
{
"type": "WEB",
"url": "https://github.com/fatedier/frp/commit/7dc7be930e2452ae93fd32f2a77f8c6fcd0b652b"
},
{
"type": "PACKAGE",
"url": "https://github.com/fatedier/frp"
},
{
"type": "WEB",
"url": "https://github.com/fatedier/frp/releases/tag/v0.70.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "frp: Unauthenticated Remote Denial of Service in the frp SSH Tunnel Gateway via Integer Overflow"
}
GHSA-26Q7-WP6G-349W
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2024-10-25 15:31In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix array out-of-bound access in SoC stats
Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
{
"affected": [],
"aliases": [
"CVE-2024-49931"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:15Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix array out-of-bound access in SoC stats\n\nCurrently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a\nmaximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()\nfunction access ath12k_soc_dp_stats::hal_reo_error using the REO\ndestination SRNG ring ID, which is incorrect. SRNG ring ID differ from\nnormal ring ID, and this usage leads to out-of-bounds array access. To\nfix this issue, modify ath12k_dp_rx_process() to use the normal ring ID\ndirectly instead of the SRNG ring ID to avoid out-of-bounds array access.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1",
"id": "GHSA-26q7-wp6g-349w",
"modified": "2024-10-25T15:31:26Z",
"published": "2024-10-21T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49931"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4aef827a41cdaf6201bbaf773c1eae4e20e967b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad791e3ec60cb66c1e4dc121ffbf872df312427d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0e4274d9dc9f8409d56d622cd3ecf7b6fd49e2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e106b7ad13c1d246adaa57df73edb8f8b8acb240"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-7
Strategy: Input Validation
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Mitigation MIT-15
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.
Mitigation MIT-11
Strategy: Environment Hardening
- Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
- Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
- For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Strategy: Environment Hardening
- Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
- For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.
Mitigation MIT-35
Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-100: Overflow Buffers
Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.