In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close().

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1793100968 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - 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: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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:1793100968 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - 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: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1792749577 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: cifs: fix session state check in     reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because     it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it     complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

  - In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag     marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail     to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to     destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after     copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches     skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result,     the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while     reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses     skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is     one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() /     xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an     unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray     writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the     source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into     freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on     its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list().
    The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a     direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's     frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each     sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in     tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue     into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for     consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but     a future consumer depending on the marker would regress silently. The same omission exists in     skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds     frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold     frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
    (CVE-2026-43503)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before     using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any     validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a     user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to     user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an     out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to     userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory     allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which     properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same     validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
    (CVE-2026-45856)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short     ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at     least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data     at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-     zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into     inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize     from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null),     exposed authencesn instances whose default authsize was invalid even though setauthsize() would have     rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an     out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range     1..3 so that no tfm can inherit an unsupported default authsize. (CVE-2026-46033)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before     payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least     header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the     attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen -     offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size()     underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) +     RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave     payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating     pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) +     RXE_ICRC_SIZE. (CVE-2026-46043)

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

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1792234299 advisory.

  - nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote     attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte     nfta_payload attribute, an skb_pull can encounter a negative skb->len. (CVE-2022-36946)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory     corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct     ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is     fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct     ieee80211_channel'. So only 1 element is allocated in this array. When doing:
    mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the     'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void
    *)((u8 *)mvm->nvm_data->channels + 1); because of the (u8 *) cast, we add only 1 to the address of the     beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just     after. Remove the spurious casting so that the pointer arithmetic works as expected. (CVE-2023-52531)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1     intercepts when completing userspace I/O When completing emulation of instruction that generated a     userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction     execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies     the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted     despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is     completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended     recipient) can reach the code in question. gp_interception()'s use is mutually exclusive with     is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with     EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception     during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due     to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at     arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass     CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware     name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170     [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610     [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm]
    __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>     (CVE-2025-40026)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free     on registration failure Make sure to release the sibling interfaces in case controller registration fails     to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by     Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. (CVE-2026-64471)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the     sample count to the packet payload isight_packet() takes the frame count from the device iso packet and     checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if     (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso     header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples()     then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 *     MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past     MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area.
    The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET     keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches     this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate. (CVE-2026-64483)

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

The CentOS Linux 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS6:CLSA-2026:1791949745 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report     buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it     during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted     report. (CVE-2024-50302)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-     bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that     exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-     of-bounds accesses later, e.g. in usb_destroy_configuration. (CVE-2024-53197)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace     cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid,     creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can     also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied     without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to     request the key. (CVE-2026-46243)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access     bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same     socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial     Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework     bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking     the child socket. (CVE-2026-52918)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP     rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind     skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is     addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking     skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would     reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender     hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to     skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only     safely reads the ARP header; it does not make the later sender hardware address range writable. If that     range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits()     maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable     before reading the ARP header and before calling skb_store_bits(). (CVE-2026-53266)

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

  - In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns:
    hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >=     DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of     port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
    because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array     overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function     returns. (CVE-2021-47548)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a suspicious RCU usage     warning I received the following warning while running cthon against an ontap server running pNFS: [     57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523]     6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525]     net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that     might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks     held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted     6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU     Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [     57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556]     rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596]     rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621]     ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646]     rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
    __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [     57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728]     ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754]     nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [     57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files     e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4     c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
    __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891]     nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913]     do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921]     filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930]     nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947]     nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
    __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [     57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982]     RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00     90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83     ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
    0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [     57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
    00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated---     (CVE-2023-52623)

  - In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal     suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is     caused by the fact that the postsuspend and resume methods were not paired correctly; there were two     consecutive calls to the origin_postsuspend function. The second call attempts to remove the hash_list     entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it     calls the preresume and resume methods of the table's targets. If a preresume method of some target fails,     we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return     errors. We can't return success, because then the resume and postsuspend methods would not be paired     correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools,     but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56!     invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware     name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP:
    0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX:
    000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0     RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10:
    0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0     R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010     DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0     Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ?     do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ?
    __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0     [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot]     dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0     [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10     [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0     entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]---     (CVE-2024-26880)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending     destroy work before exit_net release Similar to 2c9f0293280e (netfilter: nf_tables: flush pending destroy     work before netlink notifier) to address a race between exit_net and the destroy workqueue. The trace     below shows an element to be released via destroy workqueue while exit_net path (triggered via module     removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-     use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at     addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not     tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [     1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014]     print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590     [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ?     nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312]     nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ?
    __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [     1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ?
    __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10     [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690]     ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726]     kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750]
    __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771]     nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [     1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [     1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953]
    ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120     [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [     1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019]     kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036]
    __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0     [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221]     ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236]     unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254]     nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [     1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list
    *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349     list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list);
    11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354     list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356     nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat
    ---truncated--- (CVE-2024-35899)

  - In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with     dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which     are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time     we use it the elements may already be pointing to freed/reused memory. (CVE-2024-35950)

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.

  - slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim     reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup.
    tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via     tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader     functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private     struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line     discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup     processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized     cleanly by slip_close(). (CVE-2026-90057)

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

ID	Name	Product	Family	Type	Severity
373068	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Rocky Linux Local Security Checks	Local	high
373062	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Alma Linux Local Security Checks	Local	high
371225	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1792749577)	Nessus	CentOS Local Security Checks	Local	high
369489	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792234299)	Nessus	CentOS Local Security Checks	Local	high
367921	CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1791949745)	Nessus	CentOS Local Security Checks	Local	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
366778	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1792243434)	Nessus	Alma Linux Local Security Checks	Local	medium
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
347403	Linux Distros Unpatched Vulnerability : CVE-2026-90057	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-90057

high

Tenable Plugins

high

high

high

high

high

high

medium

high

high

high

high