linux-cve-announce - CVE-2025-38049: x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors

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: <2025041817-CVE-2025-38049-7570@gregkh>
Date: Fri, 18 Apr 2025 09:02:18 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38049: x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors

From: Greg Kroah-Hartman <gregkh@...nel.org>

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

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

x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors

Commit

  6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid")

added logic that causes resctrl to search for the CLOSID with the fewest dirty
cache lines when creating a new control group, if requested by the arch code.
This depends on the values read from the llc_occupancy counters. The logic is
applicable to architectures where the CLOSID effectively forms part of the
monitoring identifier and so do not allow complete freedom to choose an unused
monitoring identifier for a given CLOSID.

This support missed that some platforms may not have these counters.  This
causes a NULL pointer dereference when creating a new control group as the
array was not allocated by dom_data_init().

As this feature isn't necessary on platforms that don't have cache occupancy
monitors, add this to the check that occurs when a new control group is
allocated.

The Linux kernel CVE team has assigned CVE-2025-38049 to this issue.


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

	Issue introduced in 6.9 with commit 6eac36bb9eb0349c983313c71692c19d50b56878 and fixed in 6.12.23 with commit a8a1bcc27d4607227088d80483164289b5348293
	Issue introduced in 6.9 with commit 6eac36bb9eb0349c983313c71692c19d50b56878 and fixed in 6.13.11 with commit ed5addb55e403ad6598102bcf546e068ae01fef6
	Issue introduced in 6.9 with commit 6eac36bb9eb0349c983313c71692c19d50b56878 and fixed in 6.14.2 with commit 93a418fc61da13d1ee4047d4d1327990f7a2816a
	Issue introduced in 6.9 with commit 6eac36bb9eb0349c983313c71692c19d50b56878 and fixed in 6.15-rc1 with commit a121798ae669351ec0697c94f71c3a692b2a755b

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-2025-38049
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:
	arch/x86/kernel/cpu/resctrl/rdtgroup.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/a8a1bcc27d4607227088d80483164289b5348293
	https://git.kernel.org/stable/c/ed5addb55e403ad6598102bcf546e068ae01fef6
	https://git.kernel.org/stable/c/93a418fc61da13d1ee4047d4d1327990f7a2816a
	https://git.kernel.org/stable/c/a121798ae669351ec0697c94f71c3a692b2a755b