In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix initial port reference race For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference. The synchronous hangup does not prevent this race: port->tty is not assigned until tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets RFCOMM_TTY_OWNED and drops the initial reference. 4. Release drops the same initial reference again. 5. TTY cleanup drops its reference and frees the device. 6. Release performs its final tty_port_put() on the freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling.

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

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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

An update of the linux package has been released.

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1793362651 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in     gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the     superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake     up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp     via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota     objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or     if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait     completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are     still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU     callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed. (CVE-2026-63804)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index     in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using     pmdata->svid_index as an array index without bounds validation: paltmode->svid =     pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it     results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside     struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads     the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-     supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving     svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen     SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that     pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the     pmdata->svids array inside svdm_consume_modes(). (CVE-2026-64330)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while     checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via     kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it.
    Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event     create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex,     so a second thread in the same process can insert or remove events between the count and the walk. If an     event is inserted, the walk iterates more entries than were counted and writes past the end of the     ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold     p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock     is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex     and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted     and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)     (CVE-2026-74446)

  - In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on     meter attach failure While attaching a newly created meter attach_meter() function makes the new meter     visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an     error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter)     on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is     never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But     the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in     ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508     Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions     (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584)     ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated     by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set     (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree     (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ...
    netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible     until all the checks are done and the function can't fail anymore. This also makes sure the hash value     is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as     ZDI-CAN-31642. (CVE-2026-74465)

  - In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use     system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device     drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via     vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global     system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving     page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending     (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page     reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free /     General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address     0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [     196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073]     virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0     Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses     page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting     worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM     during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the     driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen     by the PM core before this * function is called. */ Testing: I have verified these fixes using Google's     virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning     memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for     the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting     worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are     no longer reproducible. (CVE-2026-74481)

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

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst     refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong     because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers     the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and     checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following     refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134     [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm:
    ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX,     1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8     85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc     01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP:
    0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000     RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08:
    0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000     R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000)     GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge]
    __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa     [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ?     br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ?     vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
    __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2
    __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa     gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140     napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9     net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ?     smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6     ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1     dst_release underflow (CVE-2021-47222)

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst null     pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the     tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a     grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking.
    Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make     sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we     don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked     in the egress path. (CVE-2021-47223)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit     overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain,     instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset.
    The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset     either comes from an instruction (in which case it is 16 bit), from another register (in which case the     caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can     be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being     up to an u32, it appears that we were open to overflowing the `int`s which were currently used for     arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf     /verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e     9/kernel/bpf/verifier.c#L11904 (CVE-2023-52676)

  - 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: ubi: Fix use-after-free when volume     resizing failed There is an use-after-free problem reported by KASAN:
    ================================================================== BUG: KASAN: use-after-free in     ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2     PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard     PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44     print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi]     ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record()     returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is     holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and     vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by     not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume     resizing. (CVE-2023-53800)

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

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4850 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4850-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     October 22, 2026                              https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.113-1~deb12u1     CVE ID         : CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315                      CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937                      CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437                      CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467                      CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527                      CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795                      CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832                      CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859                      CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956                      CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002                      CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029                      CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196                      CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243                      CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528                      CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532                      CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537                      CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566                      CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594                      CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615                      CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901                      CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933                      CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939                      CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161                      CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170                      CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174                      CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182                      CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187                      CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191                      CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195                      CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199                      CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203                      CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207                      CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211                      CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215                      CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221                      CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230                      CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234                      CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238                      CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246                      CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251                      CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255                      CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262                      CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266                      CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271                      CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282                      CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291                      CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298                      CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302                      CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308                      CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314                      CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322                      CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327                      CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334                      CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339                      CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344                      CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348                      CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354                      CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360                      CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366                      CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370                      CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377                      CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381                      CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386                      CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409                      CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413                      CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421                      CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426                      CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432                      CVE-2026-98433 CVE-2026-98435 CVE-2026-98440 CVE-2026-98441                      CVE-2026-98442 CVE-2026-98443 CVE-2026-98445 CVE-2026-98448                      CVE-2026-98450 CVE-2026-98451 CVE-2026-98452 CVE-2026-98453                      CVE-2026-98454 CVE-2026-98455 CVE-2026-98456 CVE-2026-98457                      CVE-2026-98458 CVE-2026-98459 CVE-2026-98460 CVE-2026-98461                      CVE-2026-98462 CVE-2026-98464 CVE-2026-98465 CVE-2026-98468                      CVE-2026-98473 CVE-2026-98475 CVE-2026-98476 CVE-2026-98477                      CVE-2026-98479 CVE-2026-98481 CVE-2026-98482 CVE-2026-98483                      CVE-2026-98484 CVE-2026-98485 CVE-2026-98486 CVE-2026-98487                      CVE-2026-98488 CVE-2026-98489 CVE-2026-98490 CVE-2026-98491                      CVE-2026-98493 CVE-2026-98494 CVE-2026-98495 CVE-2026-98498                      CVE-2026-98499 CVE-2026-98501 CVE-2026-98502 CVE-2026-98503                      CVE-2026-98504 CVE-2026-98505 CVE-2026-98506 CVE-2026-98507                      CVE-2026-98508 CVE-2026-98509 CVE-2026-98510 CVE-2026-98511                      CVE-2026-98512 CVE-2026-98513 CVE-2026-98514 CVE-2026-98515                      CVE-2026-98516 CVE-2026-98517 CVE-2026-98519 CVE-2026-98521                      CVE-2026-98522 CVE-2026-98523 CVE-2026-98524 CVE-2026-98525                      CVE-2026-98526 CVE-2026-98527 CVE-2026-98528 CVE-2026-98529                      CVE-2026-98531 CVE-2026-98532 CVE-2026-98533 CVE-2026-98534                      CVE-2026-98535 CVE-2026-98536 CVE-2026-98537 CVE-2026-98538                      CVE-2026-98539 CVE-2026-98541 CVE-2026-98544 CVE-2026-98545                      CVE-2026-98546 CVE-2026-98547 CVE-2026-98548 CVE-2026-98549                      CVE-2026-98550 CVE-2026-98553 CVE-2026-98554 CVE-2026-98555                      CVE-2026-98559 CVE-2026-98561 CVE-2026-98565 CVE-2026-98566                      CVE-2026-98567 CVE-2026-98568 CVE-2026-98569 CVE-2026-98572                      CVE-2026-98573 CVE-2026-98575 CVE-2026-98576 CVE-2026-98577                      CVE-2026-98578 CVE-2026-98579 CVE-2026-98580 CVE-2026-98581                      CVE-2026-98582 CVE-2026-98583 CVE-2026-98586 CVE-2026-98588                      CVE-2026-98590 CVE-2026-98591 CVE-2026-98593 CVE-2026-98594                      CVE-2026-98596 CVE-2026-98597 CVE-2026-98600 CVE-2026-98601                      CVE-2026-98602 CVE-2026-98605 CVE-2026-98606 CVE-2026-98607                      CVE-2026-98608 CVE-2026-98609 CVE-2026-98610 CVE-2026-98611                      CVE-2026-98612 CVE-2026-98613 CVE-2026-98614 CVE-2026-98615                      CVE-2026-98618 CVE-2026-98620 CVE-2026-98621 CVE-2026-98622                      CVE-2026-98623 CVE-2026-98624 CVE-2026-98625 CVE-2026-98626                      CVE-2026-98629 CVE-2026-98631 CVE-2026-98632 CVE-2026-98634                      CVE-2026-98636 CVE-2026-98640 CVE-2026-98641 CVE-2026-98642                      CVE-2026-98643 CVE-2026-98644 CVE-2026-98646 CVE-2026-98647                      CVE-2026-98655 CVE-2026-98656 CVE-2026-98657 CVE-2026-98658                      CVE-2026-98660 CVE-2026-98661 CVE-2026-98662 CVE-2026-98663                      CVE-2026-98664 CVE-2026-98665 CVE-2026-98666 CVE-2026-98668                      CVE-2026-98669 CVE-2026-98670 CVE-2026-98671 CVE-2026-98672                      CVE-2026-98673 CVE-2026-98677 CVE-2026-98679 CVE-2026-98680                      CVE-2026-98681 CVE-2026-98686 CVE-2026-98687 CVE-2026-98694                      CVE-2026-98695 CVE-2026-98696 CVE-2026-98697 CVE-2026-98698                      CVE-2026-98699 CVE-2026-98700 CVE-2026-98701 CVE-2026-98702                      CVE-2026-98703 CVE-2026-98704 CVE-2026-98705 CVE-2026-98706                      CVE-2026-98707 CVE-2026-98708 CVE-2026-98709 CVE-2026-98710                      CVE-2026-98711 CVE-2026-98713 CVE-2026-98716 CVE-2026-98717                      CVE-2026-98720 CVE-2026-98721 CVE-2026-98722 CVE-2026-98725                      CVE-2026-98726 CVE-2026-98727 CVE-2026-98728 CVE-2026-98730                      CVE-2026-98731 CVE-2026-98732 CVE-2026-98733 CVE-2026-98734                      CVE-2026-98735 CVE-2026-98736 CVE-2026-98737 CVE-2026-98738                      CVE-2026-98739 CVE-2026-98741 CVE-2026-98742 CVE-2026-98743                      CVE-2026-98744 CVE-2026-98745 CVE-2026-98746 CVE-2026-98748                      CVE-2026-98749 CVE-2026-98750 CVE-2026-98751 CVE-2026-98752                      CVE-2026-98753 CVE-2026-98754 CVE-2026-98755 CVE-2026-98756                      CVE-2026-98757 CVE-2026-98758 CVE-2026-98760 CVE-2026-98761                      CVE-2026-98762 CVE-2026-98763 CVE-2026-98764 CVE-2026-98765                      CVE-2026-98766 CVE-2026-98767 CVE-2026-98768 CVE-2026-98769                      CVE-2026-98770 CVE-2026-98771 CVE-2026-98772 CVE-2026-98773                      CVE-2026-98775 CVE-2026-98777 CVE-2026-98778 CVE-2026-98779                      CVE-2026-98780 CVE-2026-98781 CVE-2026-98782 CVE-2026-98783                      CVE-2026-98784 CVE-2026-98785 CVE-2026-98790 CVE-2026-98791                      CVE-2026-98792 CVE-2026-98793 CVE-2026-98794 CVE-2026-98796                      CVE-2026-98797 CVE-2026-98798 CVE-2026-98801 CVE-2026-98805                      CVE-2026-98807 CVE-2026-98808 CVE-2026-98809 CVE-2026-98811                      CVE-2026-98812 CVE-2026-98819 CVE-2026-98822 CVE-2026-98823                      CVE-2026-98825 CVE-2026-98826 CVE-2026-98827 CVE-2026-98828                      CVE-2026-98830 CVE-2026-98831 CVE-2026-98833 CVE-2026-98835                      CVE-2026-98836 CVE-2026-98837 CVE-2026-98838 CVE-2026-98840                      CVE-2026-98841 CVE-2026-98844 CVE-2026-98845 CVE-2026-98846                      CVE-2026-98847 CVE-2026-98848 CVE-2026-98849 CVE-2026-98850                      CVE-2026-98851 CVE-2026-98852 CVE-2026-98854 CVE-2026-98855                      CVE-2026-98856 CVE-2026-98857 CVE-2026-98858 CVE-2026-98859                      CVE-2026-98860 CVE-2026-98862 CVE-2026-99999     Debian Bug     : 1149499 1149564 1150891

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.113-1~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.112 and 6.12.113.

    We recommend that you upgrade your linux-6.12 packages.

    For the detailed security status of linux-6.12 please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux-6.12

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

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

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Bluetooth: RFCOMM: Fix initial port reference race For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install()     and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference.
    The release path tests the bit separately from the install path setting it, so both can drop that     reference. The synchronous hangup does not prevent this race: port->tty is not assigned until     tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each     obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets     RFCOMM_TTY_OWNED and drops the initial reference. 4. Release drops the same initial reference again. 5.
    TTY cleanup drops its reference and frees the device. 6. Release performs its final tty_port_put() on the     freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at     addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930     sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88:
    rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0     Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370     process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes     RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference     until release or TTY cleanup, preserving the existing callback ordering and error handling.
    (CVE-2026-98739)

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

ID	Name	Product	Family	Type	Severity
376433	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Alma Linux Local Security Checks	Local	high
376432	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Rocky Linux Local Security Checks	Local	high
376285	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:5091-1)	Nessus	SuSE Local Security Checks	Local	critical
375086	Photon OS 5.0: Linux PHSA-2026-5.0-92-1044	Nessus	PhotonOS Local Security Checks	Local	critical
374204	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1793362651)	Nessus	CentOS Local Security Checks	Local	high
371988	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1792979985)	Nessus	CentOS Local Security Checks	Local	high
370518	Debian dla-4850 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
367002	Linux Distros Unpatched Vulnerability : CVE-2026-98739	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-98739

high

Tenable Plugins

high

high

critical

critical

high

high

high

high