In the Linux kernel, the following vulnerability has been resolved: netconsole: Acquire sumutex before navigating configs hierarchy There is a race between operations that iterate over the userdata cgchildren list and concurrent add/remove of userdata items through configfs. The updateuserdata() function iterates over the nt->userdatagroup.cgchildren list, and countextradataentries() also iterates over this same list to count nodes. Quoting from Documentation/filesystems/configfs.rst: > A subsystem can navigate the cgchildren list and the ciparent pointer > to see the tree created by the subsystem. This can race with configfs' > management of the hierarchy, so configfs uses the subsystem mutex to > protect modifications. Whenever a subsystem wants to navigate the > hierarchy, it must do so under the protection of the subsystem > mutex. Without proper locking, if a userdata item is added or removed concurrently while these functions are iterating, the list can be accessed in an inconsistent state. For example, the listforeach() loop can reach a node that is being removed from the list by listdelinit() which sets the nodes' .next pointer to point to itself, so the loop will never end (or reach the WARNONONCE in updateuserdata() ). Fix this by holding the configfs subsystem mutex (sumutex) during all operations that iterate over cgchildren. This includes: - userdatumvaluestore() which calls updateuserdata() to iterate over cgchildren - All sysdata*enabledstore() functions which call countextradataentries() to iterate over cgchildren The sumutex must be acquired before dynamicnetconsolemutex to avoid potential lock ordering issues, as configfs operations may already hold sumutex when calling into our code.