CVE-2026-63799: 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…

PriorityP342high7.8CVSS 3.1

AVLACLPRLUINSUCHIHAH

EPSS

0.12%

2.3th percentile

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 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 syzka

Affected

4 ranges

Vendor	Product	Version range	Fixed in
linux	linux	—	—
linux	linux	>= fbd0e71dc370af73f6b316e4de9eed273dd90340 < 8d32856fb72ba976d9c87ba405fd17e80419934c	8d32856fb72ba976d9c87ba405fd17e80419934c
linux	linux	>= fbd0e71dc370af73f6b316e4de9eed273dd90340 < de3ab9bd3133899efb92e4cd05ba4203e58fc0a3	de3ab9bd3133899efb92e4cd05ba4203e58fc0a3
linux	linux_kernel	>= 6.19 < 7.1.3	7.1.3

CVSS provenance

nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vendor_redhat7.8HIGH

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.