In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet.

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 AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1780052998 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix potential CAN frame     reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider     concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The     following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during     isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will     trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID:
    19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e     net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline]     skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline]     isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline]     can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665     can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465
    __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data     structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes     the issue reported by syzkaller but does not affect real world operation. (CVE-2022-48830)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of     misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that     the parent get the lock first. But since this deadcode is never used and the parent dir will always be set     from the callers, let's just remove it. (CVE-2023-52583)

  - In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for     return value of 'create_hist_field' Function 'create_hist_field' is called recursively at     trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer     dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2023-53005)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu     counter block leak on error path when creating new netns Here is the stack where we allocate percpu     counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c     +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table #     allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on     xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace     through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is     low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are     creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one     in xt_register_table failed). But it's worth fixing even the rare leak. (CVE-2023-53200)

  - In the Linux kernel, the following vulnerability has been resolved: spi: imx: Don't skip cleanup in     remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma     resources are not released in the error path. this is never retried later and so this is a permanent leak.
    To fix this, only skip hardware disabling if waking the device fails. (CVE-2023-53225)

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 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1780052998 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix potential CAN frame     reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider     concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The     following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during     isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will     trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID:
    19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e     net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline]     skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline]     isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline]     can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665     can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465
    __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data     structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes     the issue reported by syzkaller but does not affect real world operation. (CVE-2022-48830)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of     misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that     the parent get the lock first. But since this deadcode is never used and the parent dir will always be set     from the callers, let's just remove it. (CVE-2023-52583)

  - In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for     return value of 'create_hist_field' Function 'create_hist_field' is called recursively at     trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer     dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2023-53005)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu     counter block leak on error path when creating new netns Here is the stack where we allocate percpu     counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c     +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table #     allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on     xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace     through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is     low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are     creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one     in xt_register_table failed). But it's worth fixing even the rare leak. (CVE-2023-53200)

  - In the Linux kernel, the following vulnerability has been resolved: spi: imx: Don't skip cleanup in     remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma     resources are not released in the error path. this is never retried later and so this is a permanent leak.
    To fix this, only skip hardware disabling if waking the device fails. (CVE-2023-53225)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-011050 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    net: bcmgenet: Add a check for oversized packets

    Occasionnaly we may get oversized packets from the hardware which     exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early     check which drops the packet to avoid invoking skb_over_panic() and move     on to processing the next packet.

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

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-006927 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    net: bcmgenet: Add a check for oversized packets

    Occasionnaly we may get oversized packets from the hardware which     exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early     check which drops the packet to avoid invoking skb_over_panic() and move     on to processing the next packet.

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

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-013129 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    net: bcmgenet: Add a check for oversized packets

    Occasionnaly we may get oversized packets from the hardware which     exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early     check which drops the packet to avoid invoking skb_over_panic() and move     on to processing the next packet.

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

Note that Nessus has not tested for this issue 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.

  - net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the     hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops     the packet to avoid invoking skb_over_panic() and move on to processing the next packet. (CVE-2023-53535)

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

An update of the linux package has been released.

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
351722	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1780052998)	Nessus	Alma Linux Local Security Checks	Local	high
351610	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1780052998)	Nessus	Rocky Linux Local Security Checks	Local	high
308731	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-011050)	Nessus	Unity Linux Local Security Checks	Local	medium
308324	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-006927)	Nessus	Unity Linux Local Security Checks	Local	medium
308103	Unity Linux 20.1070e Security Update: kernel (UTSA-2026-013129)	Nessus	Unity Linux Local Security Checks	Local	medium
269363	Linux Distros Unpatched Vulnerability : CVE-2023-53535	Nessus	Misc.	Local	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2023-53535

medium

Tenable Plugins

high

high

high

medium

medium

medium

medium

high