Back

HIGH

kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths

Published Nov 12, 2025

Description

The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken.

sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct.

Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock().

Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.

Affected products

Remediation

Red Hat mitigation

Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.

Weaknesses (1)

References (11)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Nov 12, 2025
Updated Aug 5, 2026
Reserved Apr 16, 2025
NVD
Status Deferred
Modified Jul 30, 2026
Red Hat
Severity Moderate
Public date Nov 12, 2025
ENISA EUVD
Assigner Linux
Published Nov 12, 2025
Updated Aug 5, 2026
Exploited since n/a
EUVD-2025-150373