https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 09:11:37 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2025-68319 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-68319 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0169 certfr-2026-avi-0169 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0169 https://cve.radiocsirt.org/vuln/euvd-2026-315104 EUVD-2026-315104 https://cve.radiocsirt.org/vuln/euvd-2026-315104 https://cve.radiocsirt.org/vuln/fkie_cve-2025-68319 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netconsole: Acquire su_mutex before navigating configs hierarchy</p> <p>There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes.</p> <p>Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; mutex.</p> <p>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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ).</p> <p>Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netconsole: Acquire su_mutex before navigating configs hierarchy</p> <p>There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes.</p> <p>Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; mutex.</p> <p>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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ).</p> <p>Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-68319 https://cve.radiocsirt.org/vuln/ghsa-cjpj-m4wh-mgm6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netconsole: Acquire su_mutex before navigating configs hierarchy</p> <p>There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes.</p> <p>Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; mutex.</p> <p>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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ).</p> <p>Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netconsole: Acquire su_mutex before navigating configs hierarchy</p> <p>There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes.</p> <p>Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; mutex.</p> <p>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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ).</p> <p>Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata…</p> https://cve.radiocsirt.org/vuln/ghsa-cjpj-m4wh-mgm6 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68319 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 103 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netconsole: Acquire su_mutex before navigating configs hierarchy There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes. Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; 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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ). Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata_*_en…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 103 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netconsole: Acquire su_mutex before navigating configs hierarchy There is a race between operations that iterate over the userdata cg_children list and concurrent add/remove of userdata items through configfs. The update_userdata() function iterates over the nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also iterates over this same list to count nodes. Quoting from Documentation/filesystems/configfs.rst: &gt; A subsystem can navigate the cg_children list and the ci_parent pointer &gt; to see the tree created by the subsystem. This can race with configfs&#39; &gt; management of the hierarchy, so configfs uses the subsystem mutex to &gt; protect modifications. Whenever a subsystem wants to navigate the &gt; hierarchy, it must do so under the protection of the subsystem &gt; 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 list_for_each() loop can reach a node that is being removed from the list by list_del_init() which sets the nodes&#39; .next pointer to point to itself, so the loop will never end (or reach the WARN_ON_ONCE in update_userdata() ). Fix this by holding the configfs subsystem mutex (su_mutex) during all operations that iterate over cg_children. This includes: - userdatum_value_store() which calls update_userdata() to iterate over cg_children - All sysdata_*_en…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68319 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2868 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2868