In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)

redhat RHSA-2026:81552: RHSA-2026:81552: kernel security update (Important)

tuxcare CENTOS8.4:CLSA-2026:1791858083: kernel: Fix of 94 CVEs (Critical)

ubuntu_linux USN-8887-1: Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-8887-1)

ubuntu_linux USN-8889-1: Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)

ubuntu_linux USN-8886-1: Ubuntu 24.04 LTS / Ubuntu Pro Realtime 24.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-8886-1)

ubuntu_linux USN-8888-1: Ubuntu 26.04 LTS : Linux kernel (Azure) vulnerabilities (USN-8888-1)

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

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: idle: Check     acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would     cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added     empty line after if () ] (CVE-2022-50327)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in     ext4_write_info I caught a null-ptr-deref bug as follows:
    ================================================================== KASAN: null-ptr-deref in range     [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339     RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0     ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0     generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130     deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0     exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70     entry_SYSCALL_64_after_hwframe+0x44/0xa9     ================================================================== Above issue may happen as follows:
    ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt     deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount     dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem     sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info     ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null     pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being     used. (CVE-2022-50344)

  - In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix null-ptr-deref in     vkms_release() A null-ptr-deref is triggered when it tries to destroy the workqueue in     vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range     [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted     6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ?     vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000     [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110
    __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The     reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is     alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below:
    vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init()     devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put()     kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened     vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by     checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release().
    (CVE-2022-50369)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: under NFSv4.1, fix double     svc_xprt_put on rpc_create failure On error situation `clp->cl_cb_conn.cb_xprt` should not be given a     reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put     it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-     after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [     72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE)     nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm     ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE     nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet     nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6     nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs     serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0     PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV,     BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks     nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00     0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01     e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP:
    0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX:
    0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [     72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10:
    0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14:
    ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000)     knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2:
    0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] <TASK>     [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410     [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ?     dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358]     nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600]     worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [     72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] </TASK> [     72.564189] ---[ end trace 031117b1c72ec616 ]--- [ 72.566019] list_add corruption. next->prev should be     prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ------------[ cut     here ]------------ (CVE-2022-50401)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from     htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns
    -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket     silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current     bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY     when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
    (CVE-2022-50490)

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

  - In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to     erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and     last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with     iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends     up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous     entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340     vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0     drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0     kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at:
    https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL     in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix     vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
    (CVE-2022-48862)

  - In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to     protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in     vf VLAN list as false. If the periodicity task is freeing the same node, it may cause use after free     error. This patch adds a vlan list lock to protect the vlan list. (CVE-2022-49182)

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race     between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx,     cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can     come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the     one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled     event has very low sampling period and causes immediate successive NMI, causing the event to be throttled,     cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in     amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the     NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK>     amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ?     hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60
    __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0     cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK>     amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of     BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and     enable it back while returning from NMI. This will solve the issue by not enabling those events whose     active_masks are set but are not yet enabled in hw pmu. (CVE-2022-49781)

  - In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on     add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop     device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and     then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but     doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by     del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of     them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt     and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable     to lazy-init rq_qos policies because they are optional features and add to hot path overhead once     initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to     lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an     extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit()     become noop's. (CVE-2022-50550)

  - In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue     when put module's reference In current design, usb role class driver will get usb_role_switch parent's     module reference after the user get usb_role_switch device and put the reference after the user put the     usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put     the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's     reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find     module by iterating long relations. (CVE-2024-26747)

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

  - In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in     shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure     that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs     don't hold their own references to pages that are mirrored over, so failing to notify them can lead to     page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b     (khugepaged: add support of collapse for tmpfs/shmem pages), but most of the security impact of this     only came in commit 27e1f8273113 (khugepaged: enable collapse pmd for pte-mapped THP), which actually     omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
    (CVE-2022-48991)

  - In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after     suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip     link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set     eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138     xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac
    __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64     do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely     (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets     up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down()     and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to     xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the     future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the     missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if     netif_running(). However, this should not make any functional difference since the refill work should only     be active if the network interface is actually up. (CVE-2022-49687)

  - In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix repeated calls to     sock_put() when msg has more_data In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
    __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data, sock_put() will be called multiple     times. We should reset the eval variable to __SK_NONE every time more_data starts. This causes: IPv4:
    Attempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t:
    addition on 0; use-after-free. WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25     refcount_warn_saturate+0x7d/0x110 Modules linked in: CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded     Not tainted 6.0.0 #1 Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK>
    __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320     tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640     tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0     tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70
    __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0
    __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd     (CVE-2022-50536)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer     overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid     req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free     in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be     called multiple times on same ring, if system is under stress and got memory allocation error. Ring     pointer was used as an indicator of failure, but this is not correct since only ring data is     allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error     code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.
    (CVE-2023-52664)

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

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4745-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     August 18, 2026                               https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.101-1~deb12u1     CVE ID         : CVE-2025-40098 CVE-2026-45897 CVE-2026-45901 CVE-2026-53078                      CVE-2026-53090 CVE-2026-64205 CVE-2026-64280 CVE-2026-64290                      CVE-2026-64561 CVE-2026-64562 CVE-2026-64563 CVE-2026-64564                      CVE-2026-64565 CVE-2026-64567 CVE-2026-64568 CVE-2026-64569                      CVE-2026-64570 CVE-2026-64571 CVE-2026-64572 CVE-2026-64573                      CVE-2026-64574 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578                      CVE-2026-64579 CVE-2026-64580 CVE-2026-64583 CVE-2026-64584                      CVE-2026-68093 CVE-2026-68096 CVE-2026-68097 CVE-2026-68098                      CVE-2026-68099 CVE-2026-68100 CVE-2026-68102 CVE-2026-68104                      CVE-2026-68106 CVE-2026-68107 CVE-2026-68108 CVE-2026-68110                      CVE-2026-68111 CVE-2026-68112 CVE-2026-68113 CVE-2026-68115                      CVE-2026-68116 CVE-2026-68117 CVE-2026-68119 CVE-2026-68120                      CVE-2026-68121 CVE-2026-68123 CVE-2026-68124 CVE-2026-68125                      CVE-2026-68126 CVE-2026-68127 CVE-2026-68128 CVE-2026-68129                      CVE-2026-68130 CVE-2026-68131 CVE-2026-68133 CVE-2026-68135                      CVE-2026-68136 CVE-2026-68137 CVE-2026-68139 CVE-2026-68140                      CVE-2026-68141 CVE-2026-68142 CVE-2026-68143 CVE-2026-68144                      CVE-2026-68145 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148                      CVE-2026-68149 CVE-2026-68151 CVE-2026-68152 CVE-2026-68153                      CVE-2026-68154 CVE-2026-68155 CVE-2026-68156 CVE-2026-68157                      CVE-2026-68158 CVE-2026-68160 CVE-2026-68161 CVE-2026-68162                      CVE-2026-68164 CVE-2026-68165 CVE-2026-68175 CVE-2026-68176                      CVE-2026-68178 CVE-2026-68179 CVE-2026-68180 CVE-2026-68181                      CVE-2026-68182 CVE-2026-68183 CVE-2026-68184 CVE-2026-68185                      CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189                      CVE-2026-68190 CVE-2026-68192 CVE-2026-68193 CVE-2026-68194                      CVE-2026-68195 CVE-2026-68196 CVE-2026-68197 CVE-2026-68199                      CVE-2026-68200 CVE-2026-68201 CVE-2026-68202 CVE-2026-68203                      CVE-2026-68204 CVE-2026-68205 CVE-2026-68206 CVE-2026-68207                      CVE-2026-68209 CVE-2026-68210 CVE-2026-68212 CVE-2026-68213                      CVE-2026-68214 CVE-2026-68215 CVE-2026-68216 CVE-2026-68217                      CVE-2026-68218 CVE-2026-68219 CVE-2026-68220 CVE-2026-68221                      CVE-2026-68222 CVE-2026-68223 CVE-2026-68225 CVE-2026-68226                      CVE-2026-68227 CVE-2026-68228 CVE-2026-68229 CVE-2026-68231                      CVE-2026-68234 CVE-2026-68235 CVE-2026-68236 CVE-2026-68243                      CVE-2026-68244 CVE-2026-68245 CVE-2026-68246 CVE-2026-68247                      CVE-2026-68248 CVE-2026-68249 CVE-2026-68250 CVE-2026-68251                      CVE-2026-68252 CVE-2026-68255 CVE-2026-68256 CVE-2026-68257                      CVE-2026-68259 CVE-2026-68260 CVE-2026-68261 CVE-2026-68262                      CVE-2026-68263 CVE-2026-68269 CVE-2026-68271 CVE-2026-68272                      CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280                      CVE-2026-68281 CVE-2026-68284 CVE-2026-68290 CVE-2026-68293                      CVE-2026-68294 CVE-2026-68296 CVE-2026-68297 CVE-2026-68299                      CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304                      CVE-2026-68306 CVE-2026-68307 CVE-2026-68308 CVE-2026-68309                      CVE-2026-68310 CVE-2026-68311 CVE-2026-68313 CVE-2026-68314                      CVE-2026-68315 CVE-2026-68317 CVE-2026-68318 CVE-2026-68319                      CVE-2026-68320 CVE-2026-68321 CVE-2026-68324 CVE-2026-68325                      CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68329                      CVE-2026-68331 CVE-2026-68333 CVE-2026-68335 CVE-2026-68336                      CVE-2026-68338 CVE-2026-68339 CVE-2026-68340 CVE-2026-68343                      CVE-2026-68344 CVE-2026-68346 CVE-2026-68348 CVE-2026-68349                      CVE-2026-68350 CVE-2026-68351 CVE-2026-68352 CVE-2026-68353                      CVE-2026-68354 CVE-2026-68355 CVE-2026-68357 CVE-2026-68358                      CVE-2026-68359 CVE-2026-68360 CVE-2026-68361 CVE-2026-68362                      CVE-2026-68363 CVE-2026-68365 CVE-2026-68366 CVE-2026-68368                      CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68372                      CVE-2026-68373 CVE-2026-68374 CVE-2026-68376 CVE-2026-68377                      CVE-2026-68381 CVE-2026-68385 CVE-2026-68386 CVE-2026-68388                      CVE-2026-68389 CVE-2026-68391 CVE-2026-68392 CVE-2026-68394                      CVE-2026-68395 CVE-2026-68396 CVE-2026-68397 CVE-2026-68398                      CVE-2026-68402 CVE-2026-68403 CVE-2026-68405 CVE-2026-68406                      CVE-2026-68407 CVE-2026-68408 CVE-2026-68410 CVE-2026-68411                      CVE-2026-68413 CVE-2026-68414 CVE-2026-68416 CVE-2026-68417                      CVE-2026-68419 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427                      CVE-2026-68428 CVE-2026-68429 CVE-2026-68430 CVE-2026-68432                      CVE-2026-68433 CVE-2026-68434 CVE-2026-68437 CVE-2026-68439                      CVE-2026-68442 CVE-2026-68443 CVE-2026-68444 CVE-2026-68445                      CVE-2026-68446 CVE-2026-68449 CVE-2026-68450 CVE-2026-72015                      CVE-2026-72017 CVE-2026-72023 CVE-2026-72030 CVE-2026-72032                      CVE-2026-72040 CVE-2026-72045 CVE-2026-72046 CVE-2026-72051                      CVE-2026-72062 CVE-2026-72065 CVE-2026-72069 CVE-2026-72070                      CVE-2026-72101 CVE-2026-72103 CVE-2026-72113 CVE-2026-72114                      CVE-2026-72115 CVE-2026-72116 CVE-2026-72117 CVE-2026-72118                      CVE-2026-72119 CVE-2026-72121 CVE-2026-72124 CVE-2026-72125                      CVE-2026-72130 CVE-2026-72137 CVE-2026-72142 CVE-2026-72146                      CVE-2026-72147 CVE-2026-72168 CVE-2026-72175 CVE-2026-72183                      CVE-2026-72213 CVE-2026-72244 CVE-2026-72253 CVE-2026-72254                      CVE-2026-72260 CVE-2026-72299 CVE-2026-72305 CVE-2026-72372                      CVE-2026-74436     Debian Bug     : 1143721

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.  This update additionally includes many more bug fixes from     stable update 6.12.101.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.101-1~deb12u1.

    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.

An update of the linux package has been released.

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

  - drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path     releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g.,     color management failure) triggers the fail label, the error path calls dc_stream_release() again on the     same dangling pointer, causing a double release and potential use-after-free. Fix this by setting     new_stream to NULL after the initial release. (cherry picked from commit     99f3af19073b3ddbfd96e789124cce12c4277b28) (CVE-2026-68236)

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

ID	Name	Product	Family	Type	Severity
365299	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1791852988)	Nessus	CentOS Local Security Checks	Local	high
364688	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1791741836)	Nessus	Alma Linux Local Security Checks	Local	critical
364675	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1791780738)	Nessus	CentOS Local Security Checks	Local	high
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
350138	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21910-1)	Nessus	SuSE Local Security Checks	Local	high
347900	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:4254-1)	Nessus	SuSE Local Security Checks	Local	high
343049	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500248)	Nessus	Oracle Linux Local Security Checks	Local	high
337079	Debian dla-4745 : ata-modules-6.12.100+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	medium
334784	Photon OS 5.0: Linux PHSA-2026-5.0-92-0952	Nessus	PhotonOS Local Security Checks	Local	high
334182	Linux Distros Unpatched Vulnerability : CVE-2026-68236	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-68236

high

Tenable Plugins

Coming Soon

high

critical

high

high

high

high

high

medium

high

high