In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), payload_length = ntoh24(login_req->dlength); tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.

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

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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many     bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login     PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into     login->req_buf, and the login code then reads the declared length back out of that buffer - for the first     PDU in iscsi_target_locate_portal(), payload_length = ntoh24(login_req->dlength); tmpbuf =     kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in     iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed     MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the     end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in     kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167
    __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180     iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370     iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated     8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer:
    BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task     kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60     kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470     iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the     declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the     socket, so the declared length governs how much arrives rather than how much is copied out of an already-     filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose     declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req():
    isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <=     login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once     the check is in place the copy out can no longer exceed the copy in: the posted login SGE is     ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in     isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject     in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves     the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns     an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an     initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU     and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and     61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run     alternately in a single session, and a normal login still completes on the patched build. (CVE-2026-90413)

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
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
347556	Linux Distros Unpatched Vulnerability : CVE-2026-90413	Nessus	Misc.	Local	critical

Detections

Analytics

CVE-2026-90413

critical

Tenable Plugins

Coming Soon

high

critical

high

high

high

critical