CVE-2026-89744

CVE CVE-2026-89744EUVD EUVD-2026-76656Published 2026-09-11T19:46:50.000ZLast changed 2026-09-14T12:02:26.000ZCVSS 8.4

What the advisory describes

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()").

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 7.2.4; patch: 0; patch: 6.12.109; 272fcf19fda14ec603ce915aafc56cb3ea2fb38d <04004fa33730031392d987a9c1bbd8a0e1c4794b; patch: 6.18.50; 5b51b2ba5207e07bcd7be0daab2f8eea405e005e; 6.6.130 <6.6.157; 43a621684ffa47fc008be98b15ff7becaf3a72fa; 3cfdf8d27b668d122a67a14bf2bcde1a7f10bbd6 <f4ae79b5f00130aacaddb1f3eb2e5ef711fbf9e0; d1370a4f2aa0d811d419f6a6c6d257867d608956; 6.12.78 <6.12.109; 6.18.19 <6.18.50; 32752c3e81498b106da64a141379eb94f493fe6f <ba69d892ff4e4a58cc12a2cae106b112db3306cc; 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 <1900692555826753adab8799a1a8d50bb1ee200c; 5.15.203 <5.16; 64dc258f9eec1d7204e9879cb836fe29967f1239 <20ed517e416df89448029293304c9e180c26cd4b; 6.19.9 <6.20; 7.0; patch: 7.3-rc1; 6.1.167 <6.1.188; patch: 6.6.157; 5.10.253 <5.11; patch: 6.1.188; 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 <9cb6b223ef02cb5c9777a852ae1ecf5796987eb6

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.