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 Cloud Security Plugin ID 475460

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: idpf: disable DIM work before freeing
 q_vectors idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim
 are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and
 idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them.
 idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the
 ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed
 q_vector. No configuration is needed to get there -- IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and
 idpf_vport_alloc() initialises both modes to IDPF_ITR_DYNAMIC. Draining after
 idpf_vport_intr_napi_dis_all() is not enough on its own. idpf_net_dim() is called from inside the "if
 (napi_complete_done(napi, work_done))" branch of the poll, and napi_complete_done() has already cleared
 NAPIF_STATE_SCHED by then. napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED |
 NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is still queueing the work, and a
 plain cancel_work_sync() would be re-armed behind the drain. Use disable_work_sync(): schedule_work() on a
 work with a non-zero disable count is dropped by clear_pending_if_disabled() before __queue_work() is
 reached. Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are initialised on every path that
 can reach the drain -- the three "goto intr_deinit" sites between idpf_vport_intr_init() and
 idpf_vport_intr_ena() get there without the enable side having run. Nothing re-enables them:
 rsrc->q_vectors is freed on every exit from idpf_vport_open() and on every idpf_vport_stop(), so the count
 dies with the object. It is a race, not a deterministic failure -- net_dim() only schedules once
 DIM_NEVENTS events have accumulated and the profile index changes. A KASAN ifup/ifdown loop under load is
 the way to see it. (CVE-2026-97603)

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: 475460

Version: Revision 1.1

Type: Local

Published: 10/16/2026

Updated: 10/16/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5

Percentile: 93.19

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 3.5

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

CVSS Score Source: CVE-2026-97603

CVSS v3

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 4.1

Vector: CVSS:3.0/AV:L/AC:H/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-97603