Detections
Analytics

Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106

medium Tenable Self-Hosted Container Security Plugin ID 475406

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - In the Linux kernel, the following vulnerability has been resolved: sched/rt,dl: Skip migrate-disabled
 tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the
 scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the
 runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a
 task to move away, and keeps trying to move the task, but the push can never succeed. When the head is
 pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-
 CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU
 spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the
 loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected
 CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in
 rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the
 CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of
 CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head
 of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of
 those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran.
 Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock,
 then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick
 returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the
 running task from that list, so taskB can never be the head. The check expects a candidate taken from the
 pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every
 time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push
 taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares
 taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still
 queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot
 stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing.
 In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left
 the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work
 migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts
 over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA,
 still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0
 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint.
 The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is
 closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded,
 because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their
 own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinn
 ---truncated--- (CVE-2026-98087)

Solution

Update the sys-kernel/cchost-kernel-6_12 library and its related packages to version 19999.44.106 or later.

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-133.oval.xml.tar.gz

Plugin Details

Severity: Medium

ID: 475406

Version: Revision 1.1

Type: Local

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5.7

Percentile: 95.89

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4

Temporal Score: 3

Vector: CVSS2#AV:L/AC:H/Au:N/C:N/I:N/A:C

CVSS Score Source: CVE-2026-98087

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 9/25/2026

Reference Information

CVE: CVE-2026-98087