Google: sys-kernel/lakitu-kernel-6_1: security update to 17935.0.0

medium Tenable Self-Hosted Container Security Plugin ID 450569

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: autofs: fix memory leak of waitqueues
in autofs_catatonic_mode Syzkaller reports a memory leak: BUG: memory leak unreferenced object
0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump
(first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff
00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90
mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>]
autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0
fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [<ffffffff81bb6a95>]
autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl
fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>]
entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue structs should be freed if their wait_ctr
becomes zero. Otherwise they will be lost. In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a
new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that
wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition
may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or
autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places.
Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb
calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage
counter to zero which is not a correct behaviour. edit:imk This description is of course not correct. The
umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the
autofs mount itself. They happen independently, usually after everything mounted within the autofs file
system has been expired away. If everything hasn't been expired away the automount daemon can still exit
leaving mounts in place. But expires done in both cases will result in a notification that calls
autofs_wait_release() with a result status. The problem case is the summary execution of of the automount
daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount
is umounted. end edit: imk So in catatonic mode we should free waitqueues which counter becomes zero.
edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode()
was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is
removed from the list when either of these two functions are called. Consequently the wait entry will be
freed by only one of these functions or by the woken process in autofs_wait() depending on the order of
the calls. end edit: imk (CVE-2023-54134)

Solution

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

See Also

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

Plugin Details

Severity: Medium

ID: 450569

Version: Revision 1.1

Type: Local

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.42

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Low

Base Score: 3.8

Temporal Score: 2.8

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

CVSS Score Source: CVE-2023-54134

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: 7/21/2021

Reference Information

CVE: CVE-2023-54134