In the Linux kernel, the following vulnerability has been resolved: scsi: ch: Do not keep references to data transfer element devices ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device there is refused by anything that walks the list - target_core_pscsi reports "scsi_device_get() failed for H:C:T:L" - and the low-level driver's module can no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids; with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the name has been printed, and remove the now unused dt[] array. That also removes the array leaked when ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was not merged.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1793786843 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: perf: arm_spe: Prevent overflow in     PERF_IDX2OFF() Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2     GiB). (CVE-2025-40081)

  - In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error     check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in     topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic     uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to     potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation,     PTR_ERR_OR_ZERO(ptr) returns: The error code within @ptr if it is an error pointer; 0 otherwise. This     means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore     !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing     clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk)     which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
    (CVE-2025-40346)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Add support for     Van Gogh SoC The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the     Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix     suspend. Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver     to crash while trying to resume afterwards due to a power hang. (CVE-2025-68334)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - scsi: ch: Do not keep references to data transfer element devices ch_readconfig() looks up the scsi_device     of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in     ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array     with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in     the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's     device list at its address, so a new device there is refused by anything that walks the list -     target_core_pscsi reports scsi_device_get() failed for H:C:T:L - and the low-level driver's module can     no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids;
    with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four     drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the     count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the     name has been printed, and remove the now unused dt[] array. That also removes the array leaked when     ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was     not merged. (CVE-2026-99019)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
379876	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2026-121)	Nessus	Amazon Linux Local Security Checks	Local	critical
379844	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-139)	Nessus	Amazon Linux Local Security Checks	Local	critical
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	Local	high
376201	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1793786843)	Nessus	Alma Linux Local Security Checks	Local	high
371588	Linux Distros Unpatched Vulnerability : CVE-2026-99019	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-99019

medium

Tenable Plugins

critical

critical

high

high

medium