In the Linux kernel, the following vulnerability has been resolved: HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb(): timer_delete_sync(&sc->ghl_poke_timer); usb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <- hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis.

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

  - In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted     memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause     set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers     need to take care to handle these errors to avoid returning decrypted (shared) memory to the page     allocator, which could lead to functional or security issues. Leak the decrypted memory when     set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call     WARN_ONCE(). (CVE-2024-57793)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - zero initialize     memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with     sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the     use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP     patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on     proper initialization of their context structures. A particular issue has been observed with the newly     added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow     multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight     variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY     randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight     without explicitly comparing against true/false. Since inflight is only ever set to true or false later,     an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with     sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by     uninitialized data. (CVE-2025-71113)

  - In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for     %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte     stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the     formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for     v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as     [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50     visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50]     buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch     the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum     current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier     mapped-v4 example (CVE-2026-31630)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for     partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are     adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous     set checks on start elements for this reason. However, it is possible to add intervals that overlap to     this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A     C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-     chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;)     and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the     terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of     iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond     the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops     to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and     atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since     most are connector- based) 256 is a generous upper bound. (cherry picked from commit     95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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

  - In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted     memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause     set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers     need to take care to handle these errors to avoid returning decrypted (shared) memory to the page     allocator, which could lead to functional or security issues. Leak the decrypted memory when     set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call     WARN_ONCE(). (CVE-2024-57793)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - zero initialize     memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with     sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the     use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP     patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on     proper initialization of their context structures. A particular issue has been observed with the newly     added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow     multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight     variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY     randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight     without explicitly comparing against true/false. Since inflight is only ever set to true or false later,     an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with     sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by     uninitialized data. (CVE-2025-71113)

  - In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for     %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte     stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the     formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for     v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as     [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50     visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50]     buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch     the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum     current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier     mapped-v4 example (CVE-2026-31630)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for     partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are     adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous     set checks on start elements for this reason. However, it is possible to add intervals that overlap to     this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A     C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-     chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;)     and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the     terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of     iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond     the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops     to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and     atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since     most are connector- based) 256 is a generous upper bound. (cherry picked from commit     95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind For GHL (Guitar Hero Live) dongles,     sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB     completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with     timer_delete_sync() and then freed the URB with usb_free_urb(): timer_delete_sync(&sc->ghl_poke_timer);
    usb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight     the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-     arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is     allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer     (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a     disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB.
    usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that     is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync()     runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once     it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc.
    timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is     unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via     dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms     the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is     released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG:
    KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task     swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0     run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <-     hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis.
    (CVE-2026-89625)

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

ID	Name	Product	Family	Type	Severity
369491	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Rocky Linux Local Security Checks	Local	high
369490	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Alma Linux 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
345218	Linux Distros Unpatched Vulnerability : CVE-2026-89625	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-89625

high

Tenable Plugins

high

high

medium

high

high

high

high