Detections
Analytics

Google: sys-kernel/csql-kernel-6_1, sys-kernel/csql-kernel-6_6: security update to 18613.263.49

medium Tenable Self-Hosted Container Security Plugin ID 465563

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: x86/mce: use is_copy_from_user() to
 determine copy-from-user context Patch series "mm/hwpoison: Fix regressions in memory failure handling",
 v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory
 failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. -
 copyin case: poison found in user page while kernel copying from user space - instr case: poison found
 while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case:
 Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places
 get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE
 handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When
 EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a
 -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full
 recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from
 storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit
 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG,
 and later patches updated the extable fixup type for copy-from-user operations, changing it from
 EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in
 get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI
 and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the
 memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR
 signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors
 tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that
 detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an
 SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because
 it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that
 multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the
 machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and
 signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier())
 to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when
 poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol
 scrub errors, the memory controller uses it for reads too. But the memory controller is executing
 asynchronously from the core, and can't tell the difference between a "real" read and a speculative read.
 So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is
 needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the
 read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try
 to retire the load from address A. Quite often (because speculation has got better) the CMCI from the
 memory controller is delivered before the core is committed to the instruction reading address A, so the
 interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for
 instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---
 (CVE-2025-39989)

Solution

Update the sys-kernel/csql-kernel-6_1 library and its related packages to version 18613.263.49 or later.

See Also

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

Plugin Details

Severity: Medium

ID: 465563

Version: Revision 1.1

Type: Local

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5

Percentile: 93.48

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

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

CVSS Score Source: CVE-2025-39989

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: 4/18/2025

Reference Information

CVE: CVE-2025-39989