PULSE
FEED
ransomanubis reclama a Santiam Hospital & Clinics · US · Healthcareransomsilentransomgroup reclama a Lowenstein Sandler LLP · US · Professional Servicesransompear reclama a Cyrious Software · US · Technologyransomwallstreet reclama a Fortrex · US · Manufacturingransomsilentransomgroup reclama a Morrison Foerster · US · Professional Servicesransomsilentransomgroup reclama a T... E...ransomsilentransomgroup reclama a S... H...ransomgenesis reclama a A&B Lab · US · Otherransomglobal secret group reclama a The Anglican International School · IL · Educationransompanzer reclama a PQE Group · Professional Servicesransomsilentransomgroup reclama a L...ransomrhysida reclama a Noelker and Hull · US · Professional Servicesransompayload reclama a Hauhinco · DE · Manufacturingransompayload reclama a Marbre Design · Manufacturingransomanubis reclama a Santiam Hospital & Clinics · US · Healthcareransomsilentransomgroup reclama a Lowenstein Sandler LLP · US · Professional Servicesransompear reclama a Cyrious Software · US · Technologyransomwallstreet reclama a Fortrex · US · Manufacturingransomsilentransomgroup reclama a Morrison Foerster · US · Professional Servicesransomsilentransomgroup reclama a T... E...ransomsilentransomgroup reclama a S... H...ransomgenesis reclama a A&B Lab · US · Otherransomglobal secret group reclama a The Anglican International School · IL · Educationransompanzer reclama a PQE Group · Professional Servicesransomsilentransomgroup reclama a L...ransomrhysida reclama a Noelker and Hull · US · Professional Servicesransompayload reclama a Hauhinco · DE · Manufacturingransompayload reclama a Marbre Design · Manufacturing
← All CVEs
CVE WatchOct 19, 2026

CVE-2026-89744

In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() Whe

CVSS

8.4

High

EPSS

0.1%

p3

KEV

—

Exploit Today

1

0-100

Published: Sep 11, 2026 · Last modified: Oct 19, 2026

EPSS · 30d
0.1%EPSS · 30 days0.2%
2026-09-302026-10-27
Technical 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()").

Official references
Related CVEs

No related CVEs by CWE or product.