In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name.

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

  - In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after     suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip     link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set     eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138     xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac
    __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64     do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely     (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets     up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down()     and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to     xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the     future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the     missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if     netif_running(). However, this should not make any functional difference since the refill work should only     be active if the network interface is actually up. (CVE-2022-49687)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix use-after-free bug     in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to     delete slow_task->timer. However, if the timer handler sas_task_internal_timedout() is running, the     del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below:
    (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ...
    sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling     del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the     task->slow_task is deallocated. (CVE-2022-50422)

  - In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from     bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they     are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints     aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host     controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt     device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup()     when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts     that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy     Bridge) (CVE-2022-50470)

  - In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: fix return value check     of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host()     will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-     deref in device_del(). Fix this by checking the return value and goto error path which will call     mmc_free_host(). (CVE-2022-50846)

  - In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix memory leak in     uvc_gpio_parse Previously the unit buffer was allocated before checking the IRQ for privacy GPIO. In case     of error, the unit buffer was leaked. Allocate the unit buffer after the IRQ to avoid it. Addresses-     Coverity-ID: 1474639 (Resource leak) (CVE-2022-50882)

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

The Rocky Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ crxsa-2024_3138 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

    Additional Changes:

    For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes     linked from the References section.

    This advisory is provided by Ctrl IQ, Inc for Rocky Linux systems. For more information about CIQ security     practices, visit https://ciq.com/security.

Tenable has extracted the preceding description block directly from the CIQ security advisory.

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.

  - In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic     during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after     this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the     function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH     firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the     bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were     loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or     an unmatched device. This resulted in all drivers getting registered much before the warm reset     notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to     load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and     cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp     driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and     causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name.
    (CVE-2023-53392)

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

ID	Name	Product	Family	Type	Severity
362121	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1773139548)	Nessus	Alma Linux Local Security Checks	Local	high
353813	Rocky Linux 8 [CIQ] Security Update: bpftool / bpftool-debuginfo / kernel / kernel-abi-stablelists / etc Multiple Vulnerabilities (crxsa-2024_3138)	Nessus	Rocky Linux Local Security Checks	Local	critical
265557	Linux Distros Unpatched Vulnerability : CVE-2023-53392	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2023-53392

high

Tenable Plugins

high

critical

high