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-CQC3-8MFM-84P4
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-23 15:31In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry.
Call Trace:
<TASK>
iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
kthread+0x2e9/0x3a0 kernel/kthread.c:377
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
- Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0.
- Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
{
"affected": [],
"aliases": [
"CVE-2022-48862"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost: fix hung thread due to erroneous iotlb entries\n\nIn vhost_iotlb_add_range_ctx(), range size can overflow to 0 when\nstart is 0 and last is ULONG_MAX. One instance where it can happen\nis when userspace sends an IOTLB message with iova=size=uaddr=0\n(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,\nlast = ULONG_MAX ends up in the iotlb. Next time a packet is sent,\niotlb_access_ok() loops indefinitely due to that erroneous entry.\n\n\tCall Trace:\n\t \u003cTASK\u003e\n\t iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340\n\t vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366\n\t vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104\n\t vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372\n\t kthread+0x2e9/0x3a0 kernel/kthread.c:377\n\t ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n\t \u003c/TASK\u003e\n\nReported by syzbot at:\n\thttps://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87\n\nTo fix this, do two things:\n\n1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map\n a range with size 0.\n2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]\n by splitting it into two entries.",
"id": "GHSA-cqc3-8mfm-84p4",
"modified": "2024-07-23T15:31:08Z",
"published": "2024-07-16T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48862"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1"
}
],
"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-CW9G-QWF2-42HW
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.
{
"affected": [],
"aliases": [
"CVE-2021-38311"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-09T22:15:00Z",
"severity": "HIGH"
},
"details": "In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.",
"id": "GHSA-cw9g-qwf2-42hw",
"modified": "2022-05-24T19:10:37Z",
"published": "2022-05-24T19:10:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38311"
},
{
"type": "WEB",
"url": "https://github.com/contiki-os/contiki/issues/2685"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CWV3-863G-39VX
Vulnerability from github – Published: 2021-05-21 14:26 – Updated: 2024-10-31 21:22Impact
TFlite graphs must not have loops between nodes. However, this condition was not checked and an attacker could craft models that would result in infinite loop during evaluation. In certain cases, the infinite loop would be replaced by stack overflow due to too many recursive calls.
For example, the While implementation could be tricked into a scneario where both the body and the loop subgraphs are the same. Evaluating one of the subgraphs means calling the Eval function for the other and this quickly exhaust all stack space.
Patches
We have patched the issue in GitHub commit 9c1dc920d8ffb4893d6c9d27d1f039607b326743 (for the While operator) and in GitHub commit c6173f5fe66cdbab74f4f869311fe6aae2ba35f4 (in general).
The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-29591"
],
"database_specific": {
"cwe_ids": [
"CWE-674",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-18T16:46:07Z",
"nvd_published_at": "2021-05-14T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nTFlite graphs must not have loops between nodes. However, this condition was not checked and an attacker could craft models that would result in infinite loop during evaluation. In certain cases, the infinite loop would be replaced by stack overflow due to too many recursive calls.\n\nFor example, the [`While` implementation](https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc) could be tricked into a scneario where both the body and the loop subgraphs are the same. Evaluating one of the subgraphs means calling the `Eval` function for the other and this quickly exhaust all stack space.\n \n### Patches \nWe have patched the issue in GitHub commit [9c1dc920d8ffb4893d6c9d27d1f039607b326743](https://github.com/tensorflow/tensorflow/commit/9c1dc920d8ffb4893d6c9d27d1f039607b326743) (for the `While` operator) and in GitHub commit [c6173f5fe66cdbab74f4f869311fe6aae2ba35f4](https://github.com/tensorflow/tensorflow/commit/c6173f5fe66cdbab74f4f869311fe6aae2ba35f4) (in general).\n \nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution \nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360.",
"id": "GHSA-cwv3-863g-39vx",
"modified": "2024-10-31T21:22:52Z",
"published": "2021-05-21T14:26:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-cwv3-863g-39vx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29591"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/9c1dc920d8ffb4893d6c9d27d1f039607b326743"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/c6173f5fe66cdbab74f4f869311fe6aae2ba35f4"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-519.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-717.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-228.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Stack overflow due to looping TFLite subgraph"
}
GHSA-CXQW-29JQ-PCJV
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44A vulnerability has been identified in SIMATIC S7-PLCSIM V5.4 (All versions). An attacker with local access to the system could cause a Denial-of-Service condition in the application when it is used to open a specially crafted file. As a consequence, the application could enter an infinite loop, become unresponsive and must be restarted to restore the service.
{
"affected": [],
"aliases": [
"CVE-2021-25673"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-15T17:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SIMATIC S7-PLCSIM V5.4 (All versions). An attacker with local access to the system could cause a Denial-of-Service condition in the application when it is used to open a specially crafted file. As a consequence, the application could enter an infinite loop, become unresponsive and must be restarted to restore the service.",
"id": "GHSA-cxqw-29jq-pcjv",
"modified": "2022-05-24T17:44:34Z",
"published": "2022-05-24T17:44:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25673"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-256092.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F2Q5-H9MF-9537
Vulnerability from github – Published: 2023-11-01 18:30 – Updated: 2023-11-01 18:30A vulnerability in ICMPv6 inspection when configured with the Snort 2 detection engine for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the CPU of an affected device to spike to 100 percent, which could stop all traffic processing and result in a denial of service (DoS) condition. FTD management traffic is not affected by this vulnerability. This vulnerability is due to improper error checking when parsing fields within the ICMPv6 header. An attacker could exploit this vulnerability by sending a crafted ICMPv6 packet through an affected device. A successful exploit could allow the attacker to cause the device to exhaust CPU resources and stop processing traffic, resulting in a DoS condition. Note: To recover from the DoS condition, the Snort 2 Detection Engine or the Cisco FTD device may need to be restarted.
{
"affected": [],
"aliases": [
"CVE-2023-20083"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-01T18:15:09Z",
"severity": "HIGH"
},
"details": "A vulnerability in ICMPv6 inspection when configured with the Snort 2 detection engine for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the CPU of an affected device to spike to 100 percent, which could stop all traffic processing and result in a denial of service (DoS) condition. FTD management traffic is not affected by this vulnerability. This vulnerability is due to improper error checking when parsing fields within the ICMPv6 header. An attacker could exploit this vulnerability by sending a crafted ICMPv6 packet through an affected device. A successful exploit could allow the attacker to cause the device to exhaust CPU resources and stop processing traffic, resulting in a DoS condition. Note: To recover from the DoS condition, the Snort 2 Detection Engine or the Cisco FTD device may need to be restarted.",
"id": "GHSA-f2q5-h9mf-9537",
"modified": "2023-11-01T18:30:33Z",
"published": "2023-11-01T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20083"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-icmpv6-dos-4eMkLuN"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2X8-6MC7-VWRC
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2023-03-03 03:30In mpc8_read_header in libavformat/mpc8.c in Libav 12.3, an input file can result in an avio_seek infinite loop and hang, with 100% CPU consumption. Attackers could leverage this vulnerability to cause a denial of service via a crafted file.
{
"affected": [],
"aliases": [
"CVE-2019-14442"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-30T13:15:00Z",
"severity": "HIGH"
},
"details": "In mpc8_read_header in libavformat/mpc8.c in Libav 12.3, an input file can result in an avio_seek infinite loop and hang, with 100% CPU consumption. Attackers could leverage this vulnerability to cause a denial of service via a crafted file.",
"id": "GHSA-f2x8-6mc7-vwrc",
"modified": "2023-03-03T03:30:23Z",
"published": "2022-05-24T16:51:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14442"
},
{
"type": "WEB",
"url": "https://bugzilla.libav.org/show_bug.cgi?id=1159"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/09/msg00000.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F348-XH8R-WR5G
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42An FR-GV-302 issue in FreeRADIUS 3.x before 3.0.15 allows "Infinite loop and memory exhaustion with 'concat' attributes" and a denial of service.
{
"affected": [],
"aliases": [
"CVE-2017-10985"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-17T17:29:00Z",
"severity": "HIGH"
},
"details": "An FR-GV-302 issue in FreeRADIUS 3.x before 3.0.15 allows \"Infinite loop and memory exhaustion with \u0027concat\u0027 attributes\" and a denial of service.",
"id": "GHSA-f348-xh8r-wr5g",
"modified": "2022-05-13T01:42:02Z",
"published": "2022-05-13T01:42:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10985"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2389"
},
{
"type": "WEB",
"url": "http://freeradius.org/security/fuzzer-2017.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3930"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99968"
}
],
"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-F349-GQV8-WH65
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-10-30 21:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix extent range end unlock in cow_file_range()
Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent.
INFO: task kworker/u128:1:12 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000 Workqueue: btrfs-fixup btrfs_work_helper [btrfs] Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions.
(1) If the given range is never allocated, we can only wait for someone to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry afterward.
(2) Or, if some allocations are already done, we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish a zone.
The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue.
Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case.
{
"affected": [],
"aliases": [
"CVE-2025-21942"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix extent range end unlock in cow_file_range()\n\nRunning generic/751 on the for-next branch often results in a hang like\nbelow. They are both stack by locking an extent. This suggests someone\nforget to unlock an extent.\n\n INFO: task kworker/u128:1:12 blocked for more than 323 seconds.\n Not tainted 6.13.0-BTRFS-ZNS+ #503\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000\n Workqueue: btrfs-fixup btrfs_work_helper [btrfs]\n Call Trace:\n \u003cTASK\u003e\n __schedule+0x534/0xdd0\n schedule+0x39/0x140\n __lock_extent+0x31b/0x380 [btrfs]\n ? __pfx_autoremove_wake_function+0x10/0x10\n btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]\n btrfs_work_helper+0xff/0x480 [btrfs]\n ? lock_release+0x178/0x2c0\n process_one_work+0x1ee/0x570\n ? srso_return_thunk+0x5/0x5f\n worker_thread+0x1d1/0x3b0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10b/0x230\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n INFO: task kworker/u134:0:184 blocked for more than 323 seconds.\n Not tainted 6.13.0-BTRFS-ZNS+ #503\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000\n Workqueue: writeback wb_workfn (flush-btrfs-4)\n Call Trace:\n \u003cTASK\u003e\n __schedule+0x534/0xdd0\n schedule+0x39/0x140\n __lock_extent+0x31b/0x380 [btrfs]\n ? __pfx_autoremove_wake_function+0x10/0x10\n find_lock_delalloc_range+0xdb/0x260 [btrfs]\n writepage_delalloc+0x12f/0x500 [btrfs]\n ? srso_return_thunk+0x5/0x5f\n extent_write_cache_pages+0x232/0x840 [btrfs]\n btrfs_writepages+0x72/0x130 [btrfs]\n do_writepages+0xe7/0x260\n ? srso_return_thunk+0x5/0x5f\n ? lock_acquire+0xd2/0x300\n ? srso_return_thunk+0x5/0x5f\n ? find_held_lock+0x2b/0x80\n ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n __writeback_single_inode+0x5c/0x4b0\n writeback_sb_inodes+0x22d/0x550\n __writeback_inodes_wb+0x4c/0xe0\n wb_writeback+0x2f6/0x3f0\n wb_workfn+0x32a/0x510\n process_one_work+0x1ee/0x570\n ? srso_return_thunk+0x5/0x5f\n worker_thread+0x1d1/0x3b0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10b/0x230\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\nThis happens because we have another success path for the zoned mode. When\nthere is no active zone available, btrfs_reserve_extent() returns\n-EAGAIN. In this case, we have two reactions.\n\n(1) If the given range is never allocated, we can only wait for someone\n to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry\n afterward.\n\n(2) Or, if some allocations are already done, we must bail out and let\n the caller to send IOs for the allocation. This is because these IOs\n may be necessary to finish a zone.\n\nThe commit 06f364284794 (\"btrfs: do proper folio cleanup when\ncow_file_range() failed\") moved the unlock code from the inside of the\nloop to the outside. So, previously, the allocated extents are unlocked\njust after the allocation and so before returning from the function.\nHowever, they are no longer unlocked on the case (2) above. That caused\nthe hang issue.\n\nFix the issue by modifying the \u0027end\u0027 to the end of the allocated\nrange. Then, we can exit the loop and the same unlock code can properly\nhandle the case.",
"id": "GHSA-f349-gqv8-wh65",
"modified": "2025-10-30T21:30:40Z",
"published": "2025-04-01T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21942"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fcff2f55389306482ab049b4321bda49495e546"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a4041f2c47247575a6c2e53ce14f7b0ac946c33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f4863cfb29a7b4fe7625ce148d0b9000b75b802"
}
],
"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-F3Q5-VRP5-CRQJ
Vulnerability from github – Published: 2024-04-07 21:30 – Updated: 2025-11-04 18:30In FRRouting (FRR) through 9.1, an infinite loop can occur when receiving a MP/GR capability as a dynamic capability because malformed data results in a pointer not advancing.
{
"affected": [],
"aliases": [
"CVE-2024-31949"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-07T21:15:07Z",
"severity": "MODERATE"
},
"details": "In FRRouting (FRR) through 9.1, an infinite loop can occur when receiving a MP/GR capability as a dynamic capability because malformed data results in a pointer not advancing.",
"id": "GHSA-f3q5-vrp5-crqj",
"modified": "2025-11-04T18:30:46Z",
"published": "2024-04-07T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31949"
},
{
"type": "WEB",
"url": "https://github.com/FRRouting/frr/pull/15640"
},
{
"type": "WEB",
"url": "https://github.com/FRRouting/frr/pull/15640/commits/30a332dad86fafd2b0b6c61d23de59ed969a219b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F43G-CFGJ-442P
Vulnerability from github – Published: 2026-03-18 12:31 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
fs: ntfs3: check return value of indx_find to avoid infinite loop
We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition.
A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash.
This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.
{
"affected": [],
"aliases": [
"CVE-2025-71266"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-18T11:16:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: ntfs3: check return value of indx_find to avoid infinite loop\n\nWe found an infinite loop bug in the ntfs3 file system that can lead to a\nDenial-of-Service (DoS) condition.\n\nA malformed dentry in the ntfs3 filesystem can cause the kernel to hang\nduring the lookup operations. By setting the HAS_SUB_NODE flag in an\nINDEX_ENTRY within a directory\u0027s INDEX_ALLOCATION block and manipulating the\nVCN pointer, an attacker can cause the indx_find() function to repeatedly\nread the same block, allocating 4 KB of memory each time. The kernel lacks\nVCN loop detection and depth limits, causing memory exhaustion and an OOM\ncrash.\n\nThis patch adds a return value check for fnd_push() to prevent a memory\nexhaustion vulnerability caused by infinite loops. When the index exceeds the\nsize of the fnd-\u003enodes array, fnd_push() returns -EINVAL. The indx_find()\nfunction checks this return value and stops processing, preventing further\nmemory allocation.",
"id": "GHSA-f43g-cfgj-442p",
"modified": "2026-07-14T15:31:40Z",
"published": "2026-03-18T12:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71266"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ad7a1be44479503dbe5c699759861ef5b8bd70c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14c3188afbedfd5178bbabb8002487ea14b37b56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1732053c8a6b360e2d5afb1b34fe9779398b072c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/398e768d1accd1f5645492ab996005d7aa84a5b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/435d34719db0e130f6f0c621d67ed524cc1a7d10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68e32694be231c1cdb99b7637a657314e88e1a96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0ea441f44ce64fa514a415d4a9e6e2b06e7946c"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.