CVE-2026-63799 (GCVE-0-2026-63799)

Vulnerability from cvelistv5 – Published: 2026-07-19 12:02 – Updated: 2026-08-17 04:51
VLAI
Title
sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path
Summary
In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path In mm_cid_fixup_cpus_to_tasks(), when rq->curr has the target mm and mm_cid.active is set, the CID is checked with cid_in_transit() before setting the transition bit. In per-CPU mode a newly forked or exec'd task can be running with mm_cid.cid == MM_CID_UNSET because CIDs are assigned lazily on schedule-in. With cid_in_transit() the guard passes for MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET | MM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this to clear_bit() with MM_CID_UNSET as the bit number, triggering an out-of-bounds write. Symptoms: this is genuine memory corruption, but a bounded out-of-bounds write, not an arbitrary one. MM_CID_UNSET is the fixed sentinel BIT(31), so once the bad value reaches mm_cid_schedout() the cid_from_transit_cid() strip leaves MM_CID_UNSET, which fails the "cid < max_cids" convergence test and falls into mm_drop_cid() -> clear_bit(MM_CID_UNSET, mm_cidmask(mm)). The cid bitmap is embedded in the mm_struct slab object (after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus() bits wide, so clearing bit 31 is a deterministic OOB bit-clear at a fixed offset of 2^31 / 8 == 256 MiB past the bitmap base. The address is not attacker-influenced (fixed sentinel -> fixed offset) and the op only clears a single bit; what sits 256 MiB further along the direct map is whatever kernel object happens to live there, so this corrupts one bit of unpredictable kernel memory -- it is not an arbitrary-address or arbitrary-value write. It triggers only in per-CPU CID mode, when a CPU is running an active task of the target mm whose cid is still MM_CID_UNSET -- the fork()/execve() window before that task's next schedule-in assigns it a real CID -- and a per-CPU -> per-task fixup walks over it (the mode fallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred max_cids recompute in mm_cid_work_fn()). In practice syzkaller surfaced it as a KASAN use-after-free reported in __schedule -> mm_cid_switch_to, where the offending clear_bit() is inlined via mm_cid_schedout() -> mm_drop_cid(). Guard the transition-bit assignment against MM_CID_UNSET, in addition to the existing cid_in_transit() check, so the bit is only set on a genuine task-owned CID. A CPU-owned (MM_CID_ONCPU) CID of a running active task is handled by the cid_on_cpu(pcp->cid) branch above and never reaches this path, so excluding MM_CID_UNSET (and the already-transitioning case) is sufficient.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: fbd0e71dc370af73f6b316e4de9eed273dd90340 , < 8d32856fb72ba976d9c87ba405fd17e80419934c (git)
Affected: fbd0e71dc370af73f6b316e4de9eed273dd90340 , < de3ab9bd3133899efb92e4cd05ba4203e58fc0a3 (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.19
Unaffected: 0 , < 6.19 (semver)
Unaffected: 7.1.3 , ≤ 7.1.* (semver)
Unaffected: 7.2 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8d32856fb72ba976d9c87ba405fd17e80419934c",
              "status": "affected",
              "version": "fbd0e71dc370af73f6b316e4de9eed273dd90340",
              "versionType": "git"
            },
            {
              "lessThan": "de3ab9bd3133899efb92e4cd05ba4203e58fc0a3",
              "status": "affected",
              "version": "fbd0e71dc370af73f6b316e4de9eed273dd90340",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.19"
            },
            {
              "lessThan": "6.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.3",
                  "versionStartIncluding": "6.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "6.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path\n\nIn mm_cid_fixup_cpus_to_tasks(), when rq-\u003ecurr has the target mm and\nmm_cid.active is set, the CID is checked with cid_in_transit() before\nsetting the transition bit.  In per-CPU mode a newly forked or exec\u0027d\ntask can be running with mm_cid.cid == MM_CID_UNSET because CIDs are\nassigned lazily on schedule-in.  With cid_in_transit() the guard passes\nfor MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET |\nMM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this\nto clear_bit() with MM_CID_UNSET as the bit number, triggering an\nout-of-bounds write.\n\nSymptoms: this is genuine memory corruption, but a bounded out-of-bounds\nwrite, not an arbitrary one.  MM_CID_UNSET is the fixed sentinel BIT(31),\nso once the bad value reaches mm_cid_schedout() the cid_from_transit_cid()\nstrip leaves MM_CID_UNSET, which fails the \"cid \u003c max_cids\" convergence\ntest and falls into mm_drop_cid() -\u003e clear_bit(MM_CID_UNSET,\nmm_cidmask(mm)).  The cid bitmap is embedded in the mm_struct slab object\n(after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus()\nbits wide, so clearing bit 31 is a deterministic OOB bit-clear at a\nfixed offset of 2^31 / 8 == 256 MiB past the bitmap base.  The address is\nnot attacker-influenced (fixed sentinel -\u003e fixed offset) and the op only\nclears a single bit; what sits 256 MiB further along the direct map is\nwhatever kernel object happens to live there, so this corrupts one bit of\nunpredictable kernel memory -- it is not an arbitrary-address or\narbitrary-value write.\n\nIt triggers only in per-CPU CID mode, when a CPU is running an active\ntask of the target mm whose cid is still MM_CID_UNSET -- the\nfork()/execve() window before that task\u0027s next schedule-in assigns it a\nreal CID -- and a per-CPU -\u003e per-task fixup walks over it (the mode\nfallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred\nmax_cids recompute in mm_cid_work_fn()).\n\nIn practice syzkaller surfaced it as a KASAN use-after-free reported in\n__schedule -\u003e mm_cid_switch_to, where the offending clear_bit() is inlined\nvia mm_cid_schedout() -\u003e mm_drop_cid().\n\nGuard the transition-bit assignment against MM_CID_UNSET, in addition to\nthe existing cid_in_transit() check, so the bit is only set on a genuine\ntask-owned CID.  A CPU-owned (MM_CID_ONCPU) CID of a running active task\nis handled by the cid_on_cpu(pcp-\u003ecid) branch above and never reaches\nthis path, so excluding MM_CID_UNSET (and the already-transitioning case)\nis sufficient."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is reached only through local scheduler paths triggered by fork/clone, exit, and execve syscalls, not by any network, Bluetooth, or physical device interface.\nAC:L - An unprivileged attacker can deliberately create many threads to enter per-CPU CID mode, fork/exec a task that remains active with MM_CID_UNSET, and time thread exits or affinity-driven fixups to hit the vulnerable branch without depending on conditions outside their control.\nPR:L - Triggering the vulnerable fixup requires only standard unprivileged process operations (creating threads, forking, exiting) within one\u0027s own address space, including from unprivileged user namespaces.\nUI:N - Exploitation requires no action from any other user or administrator; the attacker drives the entire thread lifecycle and timing themselves.\nS:U - Impact is kernel memory corruption within the same kernel security boundary; it does not constitute a VM escape, sandbox breakout, or cross-authority boundary crossing.\nC:H - The out-of-bounds bit-clear corrupts unpredictable kernel memory at a fixed large offset, and any such memory corruption can potentially be leveraged for information disclosure even though the immediate primitive is a single-bit write.\nI:H - The vulnerability performs an out-of-bounds write via clear_bit() with bit number MM_CID_UNSET (BIT(31)), which is genuine kernel memory corruption in the integrity domain.\nA:H - Syzkaller reported this as a KASAN fault in __schedule -\u003e mm_cid_switch_to, and corrupting arbitrary kernel memory can cause kernel oops, panic, or crash-level denial of service."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:51:04.486Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8d32856fb72ba976d9c87ba405fd17e80419934c"
        },
        {
          "url": "https://git.kernel.org/stable/c/de3ab9bd3133899efb92e4cd05ba4203e58fc0a3"
        }
      ],
      "title": "sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-63799",
    "datePublished": "2026-07-19T12:02:06.341Z",
    "dateReserved": "2026-07-19T07:54:57.013Z",
    "dateUpdated": "2026-08-17T04:51:04.486Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-63799",
      "date": "2026-09-21",
      "epss": "0.00165",
      "percentile": "0.06155"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "kernel/sched/core.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "8d32856fb72ba976d9c87ba405fd17e80419934c",
                    "status": "affected",
                    "version": "fbd0e71dc370af73f6b316e4de9eed273dd90340",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "de3ab9bd3133899efb92e4cd05ba4203e58fc0a3",
                    "status": "affected",
                    "version": "fbd0e71dc370af73f6b316e4de9eed273dd90340",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "kernel/sched/core.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.19"
                  },
                  {
                    "lessThan": "6.19",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.1.*",
                    "status": "unaffected",
                    "version": "7.1.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "9526B150-E2B3-4C6F-8AE5-1AF92B75AD9E",
                    "versionEndExcluding": "7.1.3",
                    "versionStartIncluding": "6.19",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path\n\nIn mm_cid_fixup_cpus_to_tasks(), when rq-\u003ecurr has the target mm and\nmm_cid.active is set, the CID is checked with cid_in_transit() before\nsetting the transition bit.  In per-CPU mode a newly forked or exec\u0027d\ntask can be running with mm_cid.cid == MM_CID_UNSET because CIDs are\nassigned lazily on schedule-in.  With cid_in_transit() the guard passes\nfor MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET |\nMM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this\nto clear_bit() with MM_CID_UNSET as the bit number, triggering an\nout-of-bounds write.\n\nSymptoms: this is genuine memory corruption, but a bounded out-of-bounds\nwrite, not an arbitrary one.  MM_CID_UNSET is the fixed sentinel BIT(31),\nso once the bad value reaches mm_cid_schedout() the cid_from_transit_cid()\nstrip leaves MM_CID_UNSET, which fails the \"cid \u003c max_cids\" convergence\ntest and falls into mm_drop_cid() -\u003e clear_bit(MM_CID_UNSET,\nmm_cidmask(mm)).  The cid bitmap is embedded in the mm_struct slab object\n(after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus()\nbits wide, so clearing bit 31 is a deterministic OOB bit-clear at a\nfixed offset of 2^31 / 8 == 256 MiB past the bitmap base.  The address is\nnot attacker-influenced (fixed sentinel -\u003e fixed offset) and the op only\nclears a single bit; what sits 256 MiB further along the direct map is\nwhatever kernel object happens to live there, so this corrupts one bit of\nunpredictable kernel memory -- it is not an arbitrary-address or\narbitrary-value write.\n\nIt triggers only in per-CPU CID mode, when a CPU is running an active\ntask of the target mm whose cid is still MM_CID_UNSET -- the\nfork()/execve() window before that task\u0027s next schedule-in assigns it a\nreal CID -- and a per-CPU -\u003e per-task fixup walks over it (the mode\nfallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred\nmax_cids recompute in mm_cid_work_fn()).\n\nIn practice syzkaller surfaced it as a KASAN use-after-free reported in\n__schedule -\u003e mm_cid_switch_to, where the offending clear_bit() is inlined\nvia mm_cid_schedout() -\u003e mm_drop_cid().\n\nGuard the transition-bit assignment against MM_CID_UNSET, in addition to\nthe existing cid_in_transit() check, so the bit is only set on a genuine\ntask-owned CID.  A CPU-owned (MM_CID_ONCPU) CID of a running active task\nis handled by the cid_on_cpu(pcp-\u003ecid) branch above and never reaches\nthis path, so excluding MM_CID_UNSET (and the already-transitioning case)\nis sufficient."
          }
        ],
        "id": "CVE-2026-63799",
        "lastModified": "2026-08-17T05:17:16.260",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-07-19T12:16:52.433",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/8d32856fb72ba976d9c87ba405fd17e80419934c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/de3ab9bd3133899efb92e4cd05ba4203e58fc0a3"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-125"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "None",
      "current_release_date": "2026-07-21T08:04:31+00:00",
      "cve": "CVE-2026-63799",
      "id": "CVE-2026-63799",
      "initial_release_date": "2026-07-19T00:00:00+00:00",
      "product_status:known_not_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-63799.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-06T01:11:36Z",
      "cve": "CVE-2026-63799",
      "id": "CVE-2026-63799",
      "initial_release_date": "2026-07-19T17:35:07Z",
      "product_status:known_not_affected": "286",
      "product_status:recommended": "4",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-63799",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-63799.json",
      "version": "5"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.


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.