| From bippy-1.2.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-38049: x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors |
| |
| 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 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 |
