CVE-2026-89744
massInfinite-loop kernel hang in Linux fwnode_for_each_child_node()
A flaw in the Linux kernel's device property framework causes fwnode_for_each_child_node() to loop forever when a firmware node (fwnode) carries a secondary fwnode that has more than one child. Once iteration crosses from the primary node's children into the secondary node's, the next call on the primary node incorrectly returns its first child again, restarting the cycle and producing an unkillable kernel loop (soft lockup) that can hang the task or freeze the system. The bug is triggered by any code path that enumerates children of a primary-plus-secondary fwnode layout, such as ACPI or device-tree nodes with attached software nodes, and is rated CVSS 8.4 with a local attack vector, meaning in practice a local denial of service. All Linux kernel versions lacking the fix are affected; the patch resolves the issue by checking the current child's parent fwnode before advancing. No public proof-of-concept exists, the issue is not in CISA's KEV, and no exploitation has been reported.
What to do: Upgrade to kernel builds that include the fix, which dynamically checks the parent fwnode of the current child before calling get_next_child_node(); apply your distribution's updated kernel packages as soon as they ship. Watch for soft lockups or boot-time hangs traced to fwnode_get_next_child_node() on systems mixing ACPI/device-tree with software nodes, and reboot any affected machine as immediate recovery.
| Linux kernel | Versions prior to the fix commit; the advisory does not specify exact version ranges |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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()").
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.