{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.3-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ecurr 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 \u003c max_cids\" convergence test and falls into mm_drop_cid() -\u003e 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 -\u003e 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 -\u003e 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 -\u003e mm_cid_switch_to, where the offending clear_bit() is inlined via mm_cid_schedout() -\u003e 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-\u003ecid) branch above and never reaches this path, so excluding MM_CID_UNSET (and the already-transitioning case) is sufficient.",
  "id": "DEBIAN-CVE-2026-63799",
  "modified": "2026-09-14T16:47:38.971958091Z",
  "published": "2026-07-19T12:16:52.433Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-63799"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-63799"
  ]
}