DEBIAN-CVE-2026-63799

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2026-63799
Import Source
https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2026-63799.json
JSON Data
https://api.test.osv.dev/v1/vulns/DEBIAN-CVE-2026-63799
Upstream
Published
2026-07-19T12:16:52Z
Modified
2026-08-27T23:06:29Z
Severity
  • 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
Summary
[none]
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->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.

References

Affected packages

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source&distro=forky

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
7.1.3-1

Affected versions

6.*
6.12.38-1
6.12.41-1
6.12.43-1~bpo12+1
6.12.43-1
6.12.48-1
6.12.57-1~bpo12+1
6.12.57-1
6.12.63-1~bpo12+1
6.12.63-1
6.12.69-1~bpo12+1
6.12.69-1
6.12.73-1~bpo12+1
6.12.73-1
6.12.74-1
6.12.74-2~bpo12+1
6.12.74-2
6.12.85-1~bpo12+1
6.12.85-1
6.12.86-1~bpo12+1
6.12.86-1
6.12.88-1~bpo12+1
6.12.88-1
6.12.90-1~bpo12+1
6.12.90-1
6.12.90-2~bpo12+1
6.12.90-2
6.12.94-1~bpo12+1
6.12.94-1
6.12.95-1~bpo12+1
6.12.95-1
6.12.96-1
6.12.100-1
6.12.101-1
6.12.105-1
6.13~rc6-1~exp1
6.13~rc7-1~exp1
6.13.2-1~exp1
6.13.3-1~exp1
6.13.4-1~exp1
6.13.5-1~exp1
6.13.6-1~exp1
6.13.7-1~exp1
6.13.8-1~exp1
6.13.9-1~exp1
6.13.10-1~exp1
6.13.11-1~exp1
6.14.3-1~exp1
6.14.5-1~exp1
6.14.6-1~exp1
6.15~rc7-1~exp1
6.15-1~exp1
6.15.1-1~exp1
6.15.2-1~exp1
6.15.3-1~exp1
6.15.4-1~exp1
6.15.5-1~exp1
6.15.6-1~exp1
6.16~rc7-1~exp1
6.16-1~exp1
6.16.1-1~exp1
6.16.3-1~bpo13+1
6.16.3-1
6.16.5-1
6.16.6-1
6.16.7-1
6.16.8-1
6.16.9-1
6.16.10-1
6.16.11-1
6.16.12-1~bpo13+1
6.16.12-1
6.16.12-2
6.17.2-1~exp1
6.17.5-1~exp1
6.17.6-1
6.17.7-1
6.17.7-2
6.17.8-1~bpo13+1
6.17.8-1
6.17.9-1
6.17.10-1
6.17.11-1
6.17.12-1
6.17.13-1~bpo13+1
6.17.13-1
6.18~rc4-1~exp1
6.18~rc4-1~exp2
6.18~rc5-1~exp1
6.18~rc6-1~exp1
6.18~rc7-1~exp1
6.18.1-1~exp1
6.18.2-1~exp1
6.18.3-1
6.18.5-1~bpo13+1
6.18.5-1
6.18.8-1
6.18.9-1~bpo13+1
6.18.9-1
6.18.10-1
6.18.12-1~bpo13+1
6.18.12-1
6.18.13-1
6.18.14-1
6.18.15-1~bpo13+1
6.18.15-1
6.19~rc4-1~exp1
6.19~rc5-1~exp1
6.19~rc6-1~exp1
6.19~rc7-1~exp1
6.19~rc8-1~exp1
6.19-1~exp1
6.19.2-1~exp1
6.19.3-1~exp1
6.19.4-1~exp1
6.19.5-1~exp1
6.19.6-1
6.19.6-2~bpo13+1
6.19.6-2
6.19.8-1~bpo13+1
6.19.8-1
6.19.10-1~bpo13+1
6.19.10-1
6.19.11-1~bpo13+1
6.19.11-1
6.19.12-1
6.19.13-1~bpo13+1
6.19.13-1
6.19.14-1~bpo13+1
6.19.14-1
7.*
7.0-1~exp1
7.0.1-1~exp1
7.0.3-1
7.0.4-1~bpo13+1
7.0.4-1
7.0.7-1~bpo13+1
7.0.7-1
7.0.9-1~bpo13+1
7.0.9-1
7.0.10-1~bpo13+1
7.0.10-1
7.0.12-1
7.0.12-2~bpo13+1
7.0.12-2
7.0.13-1~bpo13+1
7.0.13-1
7.0.14-1
7.1~rc2-1~exp1
7.1~rc3-1~exp1
7.1~rc4-1~exp1
7.1~rc4-1~exp2
7.1~rc5-1~exp1
7.1~rc7-1~exp1
7.1.1-1~exp1
7.1.2-1~exp1
7.1.3-1~bpo13+1

Ecosystem specific 

{
    "urgency":  "not yet assigned"
}

Database specific

source 
"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2026-63799.json"