CVE-2026-89744
Last modified
CVE-2026-89744 is a high-severity vulnerability rated 8.4/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()").. EPSS estimates a 0.14% chance of exploitation in the next 30 days.
Description
In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()").
Metrics
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= 272fcf19fda14ec603ce915aafc56cb3ea2fb38d, < 04004fa33730031392d987a9c1bbd8a0e1c4794b; >= 3cfdf8d27b668d122a67a14bf2bcde1a7f10bbd6, < f4ae79b5f00130aacaddb1f3eb2e5ef711fbf9e0; >= 64dc258f9eec1d7204e9879cb836fe29967f1239, < 20ed517e416df89448029293304c9e180c26cd4b; >= 32752c3e81498b106da64a141379eb94f493fe6f, < ba69d892ff4e4a58cc12a2cae106b112db3306cc; >= 2692c614f8f05929d692b3dbfd3faef1f00fbaf0, < 9cb6b223ef02cb5c9777a852ae1ecf5796987eb6; >= 2692c614f8f05929d692b3dbfd3faef1f00fbaf0, < 1900692555826753adab8799a1a8d50bb1ee200c; d1370a4f2aa0d811d419f6a6c6d257867d608956; 5b51b2ba5207e07bcd7be0daab2f8eea405e005e; 43a621684ffa47fc008be98b15ff7becaf3a72fa; >= 6.1.167, < 6.1.188; >= 6.6.130, < 6.6.157; >= 6.12.78, < 6.12.109; >= 6.18.19, < 6.18.50; >= 5.10.253, < 5.11; >= 5.15.203, < 5.16; >= 6.19.9, < 6.20 |
| Linux | Linux | 7.0 |
References
Timeline
- Published
- Last Modified
- Status
- Received
Frequently Asked Questions
What is CVE-2026-89744?
How severe is CVE-2026-89744?
How do I fix CVE-2026-89744?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-89739In the Linux kernel, the following vulnerability has been re…
- CVE-2026-8974Memory safety bugs present in Firefox ESR 140.10 and Firefox…8.8
- CVE-2026-89740In the Linux kernel, the following vulnerability has been re…
- CVE-2026-89741In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-89742In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-89743In the Linux kernel, the following vulnerability has been re…7.7
- CVE-2026-89745In the Linux kernel, the following vulnerability has been re…
- CVE-2026-89746In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-89747In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-89748In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-89749In the Linux kernel, the following vulnerability has been re…
- CVE-2026-8975Memory safety bugs present in Firefox ESR 115.35, Firefox ES…8.8
Are you affected by CVE-2026-89744?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
