CVE-2026-89744
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()").
Affected products
4- osv-coords2 versions
< 6.1.188+ 1 more
- (no CPE)range: < 6.1.188
- (no CPE)range: < 7.2.7-1.1
Patches
Vulnerability mechanics
References
6- git.kernel.org/stable/c/04004fa33730031392d987a9c1bbd8a0e1c4794bnvd
- git.kernel.org/stable/c/1900692555826753adab8799a1a8d50bb1ee200cnvd
- git.kernel.org/stable/c/20ed517e416df89448029293304c9e180c26cd4bnvd
- git.kernel.org/stable/c/9cb6b223ef02cb5c9777a852ae1ecf5796987eb6nvd
- git.kernel.org/stable/c/ba69d892ff4e4a58cc12a2cae106b112db3306ccnvd
- git.kernel.org/stable/c/f4ae79b5f00130aacaddb1f3eb2e5ef711fbf9e0nvd
News mentions
0No linked articles in our index yet.