CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1052 vulnerabilities reference this CWE, most recent first.
GHSA-QXWX-HR5V-H5Q4
Vulnerability from github – Published: 2026-07-03 09:31 – Updated: 2026-07-07 18:30An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client.
{
"affected": [],
"aliases": [
"CVE-2026-11352"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T07:16:23Z",
"severity": "HIGH"
},
"details": "An issue in curl\u2019s QUIC UDP receive function allows a malicious HTTP/3 server\nto trigger a remote denial of service against a curl or libcurl client.\nBecause the helper function discards zero-length UDP datagrams before counting\nthem toward the per-call packet budget, a connected QUIC peer can continuously\nstream empty datagrams to indefinitely stall the client.",
"id": "GHSA-qxwx-hr5v-h5q4",
"modified": "2026-07-07T18:30:33Z",
"published": "2026-07-03T09:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11352"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3783438"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-11352.html"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-11352.json"
}
],
"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-R2HQ-55RV-R3G7
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An infinite loop programming error exists in the DNS server functionality of Cesanta Mongoose 6.8 library. A specially crafted DNS request can cause an infinite loop resulting in high CPU usage and Denial Of Service. An attacker can send a packet over the network to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-2909"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-07T16:29:00Z",
"severity": "HIGH"
},
"details": "An infinite loop programming error exists in the DNS server functionality of Cesanta Mongoose 6.8 library. A specially crafted DNS request can cause an infinite loop resulting in high CPU usage and Denial Of Service. An attacker can send a packet over the network to trigger this vulnerability.",
"id": "GHSA-r2hq-55rv-r3g7",
"modified": "2022-05-13T01:01:13Z",
"published": "2022-05-13T01:01:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2909"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0416"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R4V2-QG7M-3XRH
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11The web server in InterNiche NicheStack through 4.0.1 allows remote attackers to cause a denial of service (infinite loop and networking outage) via an unexpected valid HTTP request such as OPTIONS. This occurs because the HTTP request handler enters a miscoded wbs_loop() debugger hook.
{
"affected": [],
"aliases": [
"CVE-2021-27565"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-19T12:15:00Z",
"severity": "HIGH"
},
"details": "The web server in InterNiche NicheStack through 4.0.1 allows remote attackers to cause a denial of service (infinite loop and networking outage) via an unexpected valid HTTP request such as OPTIONS. This occurs because the HTTP request handler enters a miscoded wbs_loop() debugger hook.",
"id": "GHSA-r4v2-qg7m-3xrh",
"modified": "2022-05-24T19:11:41Z",
"published": "2022-05-24T19:11:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27565"
},
{
"type": "WEB",
"url": "https://www.forescout.com/blog/new-critical-operational-technology-vulnerabilities-found-on-nichestack"
},
{
"type": "WEB",
"url": "https://www.hcc-embedded.com"
},
{
"type": "WEB",
"url": "https://www.hcc-embedded.com/about/about-interniche"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/608209"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R4VQ-5VWR-W52J
Vulnerability from github – Published: 2022-08-19 00:00 – Updated: 2022-08-23 00:00libjpeg commit 842c7ba was discovered to contain an infinite loop via the component JPEG::ReadInternal.
{
"affected": [],
"aliases": [
"CVE-2022-35166"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-18T05:15:00Z",
"severity": "MODERATE"
},
"details": "libjpeg commit 842c7ba was discovered to contain an infinite loop via the component JPEG::ReadInternal.",
"id": "GHSA-r4vq-5vwr-w52j",
"modified": "2022-08-23T00:00:18Z",
"published": "2022-08-19T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35166"
},
{
"type": "WEB",
"url": "https://github.com/thorfdbg/libjpeg/issues/76"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R52X-QXPQ-PV5M
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Skip currently executing CPU in rto_next_cpu()
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.
The trigging scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func
Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.
{
"affected": [],
"aliases": [
"CVE-2026-45919"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u003eprio \u003c rq-\u003edonor-\u003eprio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u003erto_loop_next. Even when rd-\u003erto_cpu is set to -1, the mismatch between\nrd-\u003erto_loop and rd-\u003erto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026\u0026 rt_nr_total \u003e 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n cpu0 cpu1 cpu2\n pull_rt_task\n tell_cpu_to_push\n \u003c------------irq_work_queue_on\nrto_push_irq_work_func\n push_rt_task\n resched_curr(rq) pull_rt_task\n rto_next_cpu tell_cpu_to_push\n \u003c-------------------------- atomic_inc(rto_loop_next)\nrd-\u003erto_loop != next\n rto_next_cpu\n irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.",
"id": "GHSA-r52x-qxpq-pv5m",
"modified": "2026-06-24T18:32:28Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16ca9f3117e9a294646c897daf08a5ab546c711b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b3c672a66db3de3b40f8a7057864bc1f874ede3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52aeb1e07ec223caf212f036817976c98d2aa250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ad5577b2d4acfd83f03d97a0aece2d18aac5f07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94894c9c477e53bcea052e075c53f89df3d2a33e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f25edc5a20cb52a5abbf25f0724bb4732b81801"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6a73403733e86748421f2eeaf028c85683ef896"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d57d0746276a88ea43a2cc62b849fd8a95e32e41"
}
],
"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-R649-M379-RRF8
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15Irfanview 4.57 is affected by an infinite loop when processing a crafted BMP file in the EFFECTS!AutoCrop_W component. This can cause a denial of service (DOS).
{
"affected": [],
"aliases": [
"CVE-2021-29365"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-28T16:15:00Z",
"severity": "MODERATE"
},
"details": "Irfanview 4.57 is affected by an infinite loop when processing a crafted BMP file in the EFFECTS!AutoCrop_W component. This can cause a denial of service (DOS).",
"id": "GHSA-r649-m379-rrf8",
"modified": "2022-05-24T19:15:58Z",
"published": "2022-05-24T19:15:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29365"
},
{
"type": "WEB",
"url": "https://github.com/moshekaplan/Research/tree/main/IrfanView"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R654-X82P-F2P7
Vulnerability from github – Published: 2024-12-28 12:30 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix soft lockups in fib6_select_path under high next hop churn
Soft lockups have been observed on a cluster of Linux-based edge routers
located in a highly dynamic environment. Using the bird service, these
routers continuously update BGP-advertised routes due to frequently
changing nexthop destinations, while also managing significant IPv6
traffic. The lockups occur during the traversal of the multipath
circular linked-list in the fib6_select_path function, particularly
while iterating through the siblings in the list. The issue typically
arises when the nodes of the linked list are unexpectedly deleted
concurrently on a different core—indicated by their 'next' and
'previous' elements pointing back to the node itself and their reference
count dropping to zero. This results in an infinite loop, leading to a
soft lockup that triggers a system panic via the watchdog timer.
Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6_siblings to annotate or use the RCU APIs.
Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes.
Kernel log:
0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d -- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615 17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec 18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9 20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000 24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581 25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb
{
"affected": [],
"aliases": [
"CVE-2024-56703"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-28T10:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix soft lockups in fib6_select_path under high next hop churn\n\nSoft lockups have been observed on a cluster of Linux-based edge routers\nlocated in a highly dynamic environment. Using the `bird` service, these\nrouters continuously update BGP-advertised routes due to frequently\nchanging nexthop destinations, while also managing significant IPv6\ntraffic. The lockups occur during the traversal of the multipath\ncircular linked-list in the `fib6_select_path` function, particularly\nwhile iterating through the siblings in the list. The issue typically\narises when the nodes of the linked list are unexpectedly deleted\nconcurrently on a different core\u2014indicated by their \u0027next\u0027 and\n\u0027previous\u0027 elements pointing back to the node itself and their reference\ncount dropping to zero. This results in an infinite loop, leading to a\nsoft lockup that triggers a system panic via the watchdog timer.\n\nApply RCU primitives in the problematic code sections to resolve the\nissue. Where necessary, update the references to fib6_siblings to\nannotate or use the RCU APIs.\n\nInclude a test script that reproduces the issue. The script\nperiodically updates the routing table while generating a heavy load\nof outgoing IPv6 traffic through multiple iperf3 clients. It\nconsistently induces infinite soft lockups within a couple of minutes.\n\nKernel log:\n\n 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb\n 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3\n 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4\n 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03\n 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f\n 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756\n 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af\n 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d\n-- \u003cIRQ stack\u003e --\n 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb\n [exception RIP: fib6_select_path+299]\n RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287\n RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000\n RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618\n RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200\n R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830\n R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c\n10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c\n11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5\n12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47\n13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0\n14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274\n15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474\n16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615\n17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec\n18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3\n19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9\n20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]\n21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]\n22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]\n23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000\n24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581\n25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9\n26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47\n27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30\n28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f\n29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64\n30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb",
"id": "GHSA-r654-x82p-f2p7",
"modified": "2026-07-14T15:31:16Z",
"published": "2024-12-28T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56703"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11edcd026012ac18acee0f1514db3ed1b160fc6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34a949e7a0869dfa31a40416d2a56973fae1807b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52da02521ede55fb86546c3fffd9377b3261b91f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0ec61c9f3583b76aebdbb271f5c0d3fcccd48b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9ccb18f83ea2bb654289b6ecf014fd267cc988b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.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-R68C-P976-5JMG
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2024-09-18 18:30In the Linux kernel, the following vulnerability has been resolved:
PCI: pciehp: Fix infinite loop in IRQ handler upon power fault
The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:
If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot.
The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots").
Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.
{
"affected": [],
"aliases": [
"CVE-2021-47617"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T11:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Fix infinite loop in IRQ handler upon power fault\n\nThe Power Fault Detected bit in the Slot Status register differs from\nall other hotplug events in that it is sticky: It can only be cleared\nafter turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:\n\n If a power controller detects a main power fault on the hot-plug slot,\n it must automatically set its internal main power fault latch [...].\n The main power fault latch is cleared when software turns off power to\n the hot-plug slot.\n\nThe stickiness used to cause interrupt storms and infinite loops which\nwere fixed in 2009 by commits 5651c48cfafe (\"PCI pciehp: fix power fault\ninterrupt storm problem\") and 99f0169c17f3 (\"PCI: pciehp: enable\nsoftware notification on empty slots\").\n\nUnfortunately in 2020 the infinite loop issue was inadvertently\nreintroduced by commit 8edf5332c393 (\"PCI: pciehp: Fix MSI interrupt\nrace\"): The hardirq handler pciehp_isr() clears the PFD bit until\npciehp\u0027s power_fault_detected flag is set. That happens in the IRQ\nthread pciehp_ist(), which never learns of the event because the hardirq\nhandler is stuck in an infinite loop. Fix by setting the\npower_fault_detected flag already in the hardirq handler.",
"id": "GHSA-r68c-p976-5jmg",
"modified": "2024-09-18T18:30:48Z",
"published": "2024-06-20T12:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47617"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a"
}
],
"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-R69P-RC7C-RR2M
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33A vulnerability was found in the way RemoteMessageChannel, introduced in jboss-remoting versions 3.3.10, reads from an empty buffer. An attacker could use this flaw to cause denial of service via high CPU caused by an infinite loop.
{
"affected": [],
"aliases": [
"CVE-2018-1041"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-15T17:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in the way RemoteMessageChannel, introduced in jboss-remoting versions 3.3.10, reads from an empty buffer. An attacker could use this flaw to cause denial of service via high CPU caused by an infinite loop.",
"id": "GHSA-r69p-rc7c-rr2m",
"modified": "2022-05-13T01:33:35Z",
"published": "2022-05-13T01:33:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1041"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0268"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0269"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0270"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0271"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0275"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1530457"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44099"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040323"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R73J-PQJ5-W3X7
Vulnerability from github – Published: 2026-05-04 20:19 – Updated: 2026-05-13 13:41Impact
An attacker can supply a malicious PDF that causes the process to hang indefinitely, consuming 100% CPU and making the application unresponsive.
Patches
Patched version: 12.2.0.
PdfParser (introduced in Pillow 4.2.0) follows Prev pointers in PDF trailers to read cross-reference sections. If a trailer's Prev pointer references an offset that has already been processed — either pointing to itself or forming a longer cycle — the parser enters an infinite loop. Pillow now tracks previously processed trailer offsets and raises an error if a cycle is detected.
Workarounds
Use any version but the affected versions: >= 4.2.0, < 12.2.0
Resources
- Fix: https://github.com/python-pillow/Pillow/pull/9519
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pillow"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "12.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42310"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T20:19:30Z",
"nvd_published_at": "2026-05-09T06:16:10Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn attacker can supply a malicious PDF that causes the process to hang indefinitely, consuming 100% CPU and making the application unresponsive.\n\n### Patches\nPatched version: 12.2.0.\n\nPdfParser (introduced in Pillow 4.2.0) follows Prev pointers in PDF trailers to read cross-reference sections. If a\ntrailer\u0027s Prev pointer references an offset that has already been processed \u2014 either pointing to itself or forming a\nlonger cycle \u2014 the parser enters an infinite loop. Pillow now tracks previously processed trailer offsets and raises an\nerror if a cycle is detected.\n\n### Workarounds\nUse any version but the affected versions: \u003e= 4.2.0, \u003c 12.2.0\n\n### Resources\n - Fix: https://github.com/python-pillow/Pillow/pull/9519",
"id": "GHSA-r73j-pqj5-w3x7",
"modified": "2026-05-13T13:41:22Z",
"published": "2026-05-04T20:19:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-r73j-pqj5-w3x7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42310"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/pull/9519"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/3bf614e4b8615d0ce1d5039efaf6db447fe7c468"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/releases/tag/12.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pillow has a PDF Parsing Trailer Infinite Loop (DoS)"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.