linux-cve-announce - CVE-2024-50271: signal: restore the override

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2024111929-CVE-2024-50271-9089@gregkh>
Date: Tue, 19 Nov 2024 02:32:26 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-50271: signal: restore the override_rlimit logic

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

signal: restore the override_rlimit logic

Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals.  However now it's enforced unconditionally, even if
override_rlimit is set.  This behavior change caused production issues.  

For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo. 
This prevents the process from correctly identifying the fault address and
handling the error.  From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'.  This can lead to unpredictable behavior and
crashes, as we observed with java applications.

Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set.  This effectively
restores the old behavior.

The Linux kernel CVE team has assigned CVE-2024-50271 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.14 with commit d64696905554 and fixed in 6.1.117 with commit 012f4d5d25e9
	Issue introduced in 5.14 with commit d64696905554 and fixed in 6.6.61 with commit 4877d9b2a2eb
	Issue introduced in 5.14 with commit d64696905554 and fixed in 6.11.8 with commit 0208ea17a1e4
	Issue introduced in 5.14 with commit d64696905554 and fixed in 6.12 with commit 9e05e5c7ee87

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-50271
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	include/linux/user_namespace.h
	kernel/signal.c
	kernel/ucount.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1
	https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7
	https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40
	https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed