Detections
Analytics

Google: sys-kernel/lakitu-kernel-6_1, sys-kernel/lakitu-kernel-6_6: security update to 18613.0.57

medium Tenable Self-Hosted Container Security Plugin ID 471676

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: fix bitmap corruption on close_range()
 with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first
 count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying
 enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits
 past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most
 of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open
 descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in
 ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
 which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the
 common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are
 fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where
 max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] -
 close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being
 above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors.
 In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all
 descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
 up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to
 deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try
 to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make
 copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a
 multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper
 for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so
 it'll generate plain memcpy()+memset(). Reproducer added to
 tools/testing/selftests/core/close_range_test.c (CVE-2024-45025)

Solution

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

See Also

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

Plugin Details

Severity: Medium

ID: 471676

Version: Revision 1.1

Type: Local

Published: 10/3/2026

Updated: 10/3/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5.7

Percentile: 97

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-2024-45025

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/11/2024

Reference Information

CVE: CVE-2024-45025