GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-HM85-HR96-4GWF

Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-08-29 03:30
VLAI
Details

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

sched/core: Fix use-after-free bug in dup_user_cpus_ptr()

Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel.

Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches.

Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock.

Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-415"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T07:15:05Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Fix use-after-free bug in dup_user_cpus_ptr()\n\nSince commit 07ec77a1d4e8 (\"sched: Allow task CPU affinity to be\nrestricted on asymmetric systems\"), the setting and clearing of\nuser_cpus_ptr are done under pi_lock for arm64 architecture. However,\ndup_user_cpus_ptr() accesses user_cpus_ptr without any lock\nprotection. Since sched_setaffinity() can be invoked from another\nprocess, the process being modified may be undergoing fork() at\nthe same time.  When racing with the clearing of user_cpus_ptr in\n__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and\npossibly double-free in arm64 kernel.\n\nCommit 8f9ea86fdf99 (\"sched: Always preserve the user requested\ncpumask\") fixes this problem as user_cpus_ptr, once set, will never\nbe cleared in a task\u0027s lifetime. However, this bug was re-introduced\nin commit 851a723e45d1 (\"sched: Always clear user_cpus_ptr in\ndo_set_cpus_allowed()\") which allows the clearing of user_cpus_ptr in\ndo_set_cpus_allowed(). This time, it will affect all arches.\n\nFix this bug by always clearing the user_cpus_ptr of the newly\ncloned/forked task before the copying process starts and check the\nuser_cpus_ptr state of the source task under pi_lock.\n\nNote to stable, this patch won\u0027t be applicable to stable releases.\nJust copy the new dup_user_cpus_ptr() function over.",
  "id": "GHSA-hm85-hr96-4gwf",
  "modified": "2024-08-29T03:30:49Z",
  "published": "2024-08-21T09:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48892"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7b5cc7fd1789ea5dbb942c9f8207b076d365badc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87ca4f9efbd7cc649ff43b87970888f2812945b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b22faa21b6230d5eccd233e1b7e0026a5002b287"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…