CVE-2025-68319

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netconsole: Acquire su_mutex before navigating configs hierarchy<br /> <br /> There is a race between operations that iterate over the userdata<br /> cg_children list and concurrent add/remove of userdata items through<br /> configfs. The update_userdata() function iterates over the<br /> nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also<br /> iterates over this same list to count nodes.<br /> <br /> Quoting from Documentation/filesystems/configfs.rst:<br /> &gt; A subsystem can navigate the cg_children list and the ci_parent pointer<br /> &gt; to see the tree created by the subsystem. This can race with configfs&amp;#39;<br /> &gt; management of the hierarchy, so configfs uses the subsystem mutex to<br /> &gt; protect modifications. Whenever a subsystem wants to navigate the<br /> &gt; hierarchy, it must do so under the protection of the subsystem<br /> &gt; mutex.<br /> <br /> Without proper locking, if a userdata item is added or removed<br /> concurrently while these functions are iterating, the list can be<br /> accessed in an inconsistent state. For example, the list_for_each() loop<br /> can reach a node that is being removed from the list by list_del_init()<br /> which sets the nodes&amp;#39; .next pointer to point to itself, so the loop will<br /> never end (or reach the WARN_ON_ONCE in update_userdata() ).<br /> <br /> Fix this by holding the configfs subsystem mutex (su_mutex) during all<br /> operations that iterate over cg_children.<br /> This includes:<br /> - userdatum_value_store() which calls update_userdata() to iterate over<br /> cg_children<br /> - All sysdata_*_enabled_store() functions which call<br /> count_extradata_entries() to iterate over cg_children<br /> <br /> The su_mutex must be acquired before dynamic_netconsole_mutex to avoid<br /> potential lock ordering issues, as configfs operations may already hold<br /> su_mutex when calling into our code.