Bug 1222436 (CVE-2024-26686)

Summary: VUL-0: CVE-2024-26686: kernel: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
Product: [Novell Products] SUSE Security Incidents Reporter: SMASH SMASH <smash_bz>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: NEW --- QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: mhocko, mkoutny, rfrohl
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/400158/
Whiteboard: CVSSv3.1:SUSE:CVE-2024-26686:5.5:(AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description SMASH SMASH 2024-04-08 07:54:04 UTC 
In the Linux kernel, the following vulnerability has been resolved:

fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats

lock_task_sighand() can trigger a hard lockup.  If NR_CPUS threads call
do_task_stat() at the same time and the process has NR_THREADS, it will
spin with irqs disabled O(NR_CPUS * NR_THREADS) time.

Change do_task_stat() to use sig->stats_lock to gather the statistics
outside of ->siglock protected section, in the likely case this code will
run lockless.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-26686
https://www.cve.org/CVERecord?id=CVE-2024-26686
https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071
https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305
https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d
https://bugzilla.redhat.com/show_bug.cgi?id=2273109
Comment 4 Michal Hocko 2024-04-09 06:59:08 UTC 
There is a similar fix for gerusage and likely more because depending on the kernel version we are iterating over all threads with the siglock or other internal state locks with IRQ disabled. While this is far from ideal and while this might cause performance bottlenecks I highly doubt this is security relevant problem because that would require 2 conditions to be fullfilled
- an untrusted user would need to be allowed to spawn uncontrolled number of user threads/processes. That alone is a DoS vector. As per https://lore.kernel.org/all/CADBMgpz7k=LhktfcJhSDBDWN0oLeQxPqhOVws3fq0LNpnfOSYg@mail.gmail.com/ the getrusage path requires ~250K threads to reliably produce the lockup which is beyond reasonable
- hardlockup detector is not configured to panic the system by default - nor this is a recommended configuration.

All that being said this could be considered a scalability improvement rather than a security threat. I would just close this as WONTFIX until we have a real bug report where either do_task_stat or getrusage turn out to be real performance bottlenecks.