LiveActive security incident?Get immediate response
CVE Record

CVE-2023-52942: cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask()

In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask() It was found that the check to see if a partition could use up all the cpus from the parent cpuset in update_parent_subparts_cpumask() was incorrect. As a result, it is possible to leave parent with no effective cpu left even if there are tasks in the parent cpuset. This can lead to system panic as reported in [1]. Fix this probem by updating the check to fail the enabling the partition if parent's effective_cpus is a subset of the child's cpus_allowed. Also record the error code when an error happens in update_prstate() and add a test case where parent partition and child have the same cpu list and parent has task. Enabling partition in the child will fail in this case. [1] https://www.spinics.net/lists/cgroups/msg36254.html

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2023-52942 is a Linux kernel cpuset cgroup bug that can leave a parent cpuset with no usable CPU while it still has tasks. The reported impact is system panic, so the business risk is service interruption rather than confirmed data theft or remote compromise.

Executive priority

Treat as a reliability and availability issue. Patch during normal urgent kernel maintenance, faster for high-density container hosts or systems where a kernel panic would cause major service impact. Current sources do not support emergency response for active exploitation.

Technical view

The flaw is in update_parent_subparts_cpumask(). An incorrect check allowed a child partition to consume the parent cpuset’s effective CPUs. The upstream fix rejects enabling the child partition when the parent’s effective CPUs are a subset of the child’s allowed CPUs and adds related error handling and testing.

Likely exposure

Exposure is most relevant to Linux systems running affected kernel builds that use cgroup cpuset CPU partitioning. Container, orchestration, or performance-isolated environments may be more likely to exercise this code path. The CVE data indicates Linux 6.1-era and 6.2-related affected versions, but exact packaging varies by distribution.

Exploitation context

The source describes a crash condition and references a reported system panic. CISA KEV status is false in the provided data, and no cited source claims active exploitation. The issue appears configuration-dependent and tied to cpuset partition state, not a broadly documented remote attack path.

Researcher notes

The key condition is cpuset partition enablement where a child can consume all effective CPUs from a parent that still has tasks. The provided CVE metadata has limited severity scoring and compressed affected-version details, so confirm exact vulnerable ranges through kernel or distribution advisories.

Mitigation direction

  • Apply vendor kernel updates that include the referenced stable kernel fixes.
  • Prioritize hosts using cpuset cgroups, CPU partitioning, or container workload isolation.
  • If updates are delayed, review vendor guidance for safe cpuset configuration constraints.
  • Track distribution advisories because backport version numbers may differ from upstream kernel versions.

Validation and detection

  • Inventory Linux kernel versions across servers and container hosts.
  • Identify systems using cgroup cpuset partitioning or CPU isolation features.
  • Check vendor advisories for whether your packaged kernel includes the fix.
  • Review crash logs for kernel panic events near cpuset or cgroup changes.
Prepared
Confidence
medium
Sources
5

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-52942 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxf0af1bfc27b52a4d42510051154c61bd176a8f06, f0af1bfc27b52a4d42510051154c61bd176a8f06unaffected
LinuxLinux6.1, 0, 6.1.11, 6.2affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.