In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
sched\/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path<\/p>\n
In mm_cid_fixup_cpus_to_tasks(), when rq->curr 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’d
\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.<\/p>\n
Symptoms: 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 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 -> 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.<\/p>\n
It 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’s next schedule-in assigns it a
\nreal CID — and a per-CPU -> 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()).<\/p>\n
In practice syzkaller surfaced it as a KASAN use-after-free reported in
\n__schedule -> mm_cid_switch_to, where the offending clear_bit() is inlined
\nvia mm_cid_schedout() -> mm_drop_cid().<\/p>\n
Guard 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->cid) branch above and never reaches
\nthis path, so excluding MM_CID_UNSET (and the already-transitioning case)
\nis sufficient.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
sched\/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path<\/p>\n
In mm_cid_fixup_cpus_to_tasks(), when rq->curr has the targe<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-14876","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/14876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=14876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=14876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=14876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}