CVE-2026-97410: netconsole: take target_cleanup_list_lock in drop_netconsole_target()
In the Linux kernel, the following vulnerability has been resolved:
netconsole: take targetcleanuplistlock in dropnetconsoletarget()
dropnetconsoletarget() unlinks the target while only holding targetlistlock. However, when the underlying interface has been unregistered, netconsolenetdevevent() moves the target from targetlist to targetcleanuplist, and netconsoleprocesscleanupscore() walks that list under targetcleanuplistlock only.
If a user removes the configfs target at the same time the cleanup worker is iterating targetcleanuplist, listdel() can corrupt the list because the two paths take disjoint locks while operating on the same list node.
Acquire targetcleanuplistlock around the listdel() so the unlink is serialised against netconsoleprocesscleanupscore() regardless of which list the target currently belongs to. The state transition that downgrades STATEDEACTIVATED to STATEDISABLED is left intact and is performed under the same combined locking, preserving the existing ordering with resumetarget().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In netconsole, acquire target_cleanup_list_lock around list_del() in drop_netconsole_target(), using the same combined locking to serialize it with netconsole_process_cleanups_core() and prevent list corruption.
Event History
Frequently Asked Questions
What conditions are required to trigger the race?
A netconsole target must be removed through configfs while the underlying network interface is being unregistered or has been unregistered, causing the target to be moved to the cleanup list. The cleanup worker must concurrently be iterating that cleanup list.
What is the impact if the race occurs?
Concurrent list deletion and cleanup-list iteration can corrupt the kernel list used for netconsole target cleanup. The provided data does not specify further impact such as crash, privilege escalation, or information disclosure.
Is a system using netconsole necessarily affected?
The race concerns netconsole targets managed through configfs and the interaction between target removal, network-interface unregistration, and the cleanup worker. The data does not establish whether all netconsole configurations use configfs or are exposed to this sequence.
What change resolves the issue?
The fix acquires target_cleanup_list_lock around the target list deletion in drop_netconsole_target(). This serializes removal against netconsole_process_cleanups_core() whether the target is still on the active target list or has moved to the cleanup list.