In the Linux kernel, the following vulnerability has been resolved: HID: hidpp: fix potential UAF in hidpp_connect_event() If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().

An update of the linux package has been released.

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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 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.

  - HID: hidpp: fix potential UAF in hidpp_connect_event() If input_register_device() fails, we call     input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially     lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().
    (CVE-2026-93826)

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

ID	Name	Product	Family	Type	Severity
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
375113	Photon OS 5.0: Linux PHSA-2026-5.0-91-1014	Nessus	PhotonOS Local Security Checks	Local	high
375014	Photon OS 5.0: Linux PHSA-2026-5.0-92-1014	Nessus	PhotonOS Local Security Checks	Local	high
371428	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Rocky Linux Local Security Checks	Local	high
371426	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	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
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
366742	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:4706-1)	Nessus	SuSE Local Security Checks	Local	high
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
349956	Linux Distros Unpatched Vulnerability : CVE-2026-93826	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-93826

high

Tenable Plugins

high

high

high

high

high

high

high

medium

high

high

high

high

high