In the Linux kernel, the following vulnerability has been resolved: coresight: cti: Fix hang in cti_disable_hw() cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pm_runtime_put") With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. [ Fix build warnings ]

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

  - In the Linux kernel, the following vulnerability has been resolved: net: hns3: do not allow call     hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no     checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call     hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information     is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at     net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules     linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880]     CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS     KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [     3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc :
    napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [     3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27:
    ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [     3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20:
    0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16:
    ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12:
    0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [     3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 :
    0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 :
    0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [     3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3]     [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884     [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470]     hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888]     worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [     3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace     8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be     cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
    (CVE-2021-47400)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: isotp_sendmsg(): add     result check for wait_event_interruptible() Using wait_event_interruptible() to wait for complete     transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will     result in TX buffer has multiple accessors and the later process interferes with the previous process.
    Following is one of the problems reported by syzbot.
    ============================================================= WARNING: CPU: 0 PID: 0 at     net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted     5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014     RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390
    __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80
    __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ>     asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in     isotp_sendmsg() to avoid multiple accessers for tx buffer. (CVE-2021-47457)

  - In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer     reset and memleak Commit 761ed4a94582 (tty: serial_core: convert uart_close to use tty_port_close)     converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to     be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on     next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios     changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer     of any port that has been opened would leak on driver unbind. Note that the port lock is held when     clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e (uart: fix race     between uart_put_char() and uart_shutdown()). Also note that the tty-port shutdown() callback is not     called for console ports so it is not strictly necessary to free the buffer page after releasing the lock     (cf. d72402145ace (tty/serial: do not free trasnmit buffer page under port lock)). (CVE-2021-47527)

  - In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax     For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured.
    However, dax doesn't depend on hugetlb. Commit 414fd080d125 (mm/gup: fix gup_pmd_range() for dax) fixed     devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel     panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip     > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ?     mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ?     bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ?     filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30
    __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340     io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240     ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100
    __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ?     irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70     do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK>
    ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel     panic - not syncing: Fatal exception Kernel Offset: disabled (CVE-2022-48986)

  - In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial     read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't     proceed with reading an offset for following match. In some extreme corner cases when compressed data is     suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read     out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed     here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is     certainly a huge work to be done later, so, we'd better fix it first. [1]     https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2]     https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3]     https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ (CVE-2022-49078)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-011125 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    coresight: cti: Fix hang in cti_disable_hw()

    cti_enable_hw() and cti_disable_hw() are called from an atomic context     so shouldn't use runtime PM because it can result in a sleep when     communicating with firmware.

    Since commit 3c6656337852 (Revert firmware: arm_scmi: Add clock     management to the SCMI power domain), this causes a hang on Juno when     running the Perf Coresight tests or running this command:

      perf record -e cs_etm//u -- ls

    This was also missed until the revert commit because pm_runtime_put()     was called with the wrong device until commit 692c9a499b28 (coresight:
    cti: Correct the parameter for pm_runtime_put)

    With lock and scheduler debugging enabled the following is output:

       coresight cti_sys0: cti_enable_hw -- dev:cti_sys0  parent: 20020000.cti        BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151        in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec        preempt_count: 2, expected: 0        RCU nest depth: 0, expected: 0        INFO: lockdep is turned off.
       irq event stamp: 0        hardirqs last  enabled at (0): [<0000000000000000>] 0x0        hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948        softirqs last  enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948        softirqs last disabled at (0): [<0000000000000000>] 0x0        CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7        Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13     2022        Call trace:
        dump_backtrace+0x134/0x140         show_stack+0x20/0x58         dump_stack_lvl+0x8c/0xb8         dump_stack+0x18/0x34
        __might_resched+0x180/0x228
        __might_sleep+0x50/0x88
        __pm_runtime_resume+0xac/0xb0         cti_enable+0x44/0x120         coresight_control_assoc_ectdev+0xc0/0x150         coresight_enable_path+0xb4/0x288         etm_event_start+0x138/0x170         etm_event_add+0x48/0x70         event_sched_in.isra.122+0xb4/0x280         merge_sched_in+0x1fc/0x3d0         visit_groups_merge.constprop.137+0x16c/0x4b0         ctx_sched_in+0x114/0x1f0         perf_event_sched_in+0x60/0x90         ctx_resched+0x68/0xb0         perf_event_exec+0x138/0x508         begin_new_exec+0x52c/0xd40         load_elf_binary+0x6b8/0x17d0         bprm_execve+0x360/0x7f8         do_execveat_common.isra.47+0x218/0x238
        __arm64_sys_execve+0x48/0x60         invoke_syscall+0x4c/0x110         el0_svc_common.constprop.4+0xfc/0x120         do_el0_svc+0x34/0xc0         el0_svc+0x40/0x98         el0t_64_sync_handler+0x98/0xc0         el0t_64_sync+0x170/0x174

    Fix the issue by removing the runtime PM calls completely. They are not     needed here because it must have already been done when building the     path for a trace.

    [ Fix build warnings ]

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

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-006926 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    coresight: cti: Fix hang in cti_disable_hw()

    cti_enable_hw() and cti_disable_hw() are called from an atomic context     so shouldn't use runtime PM because it can result in a sleep when     communicating with firmware.

    Since commit 3c6656337852 (Revert firmware: arm_scmi: Add clock     management to the SCMI power domain), this causes a hang on Juno when     running the Perf Coresight tests or running this command:

      perf record -e cs_etm//u -- ls

    This was also missed until the revert commit because pm_runtime_put()     was called with the wrong device until commit 692c9a499b28 (coresight:
    cti: Correct the parameter for pm_runtime_put)

    With lock and scheduler debugging enabled the following is output:

       coresight cti_sys0: cti_enable_hw -- dev:cti_sys0  parent: 20020000.cti        BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151        in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec        preempt_count: 2, expected: 0        RCU nest depth: 0, expected: 0        INFO: lockdep is turned off.
       irq event stamp: 0        hardirqs last  enabled at (0): [<0000000000000000>] 0x0        hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948        softirqs last  enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948        softirqs last disabled at (0): [<0000000000000000>] 0x0        CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7        Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13     2022        Call trace:
        dump_backtrace+0x134/0x140         show_stack+0x20/0x58         dump_stack_lvl+0x8c/0xb8         dump_stack+0x18/0x34
        __might_resched+0x180/0x228
        __might_sleep+0x50/0x88
        __pm_runtime_resume+0xac/0xb0         cti_enable+0x44/0x120         coresight_control_assoc_ectdev+0xc0/0x150         coresight_enable_path+0xb4/0x288         etm_event_start+0x138/0x170         etm_event_add+0x48/0x70         event_sched_in.isra.122+0xb4/0x280         merge_sched_in+0x1fc/0x3d0         visit_groups_merge.constprop.137+0x16c/0x4b0         ctx_sched_in+0x114/0x1f0         perf_event_sched_in+0x60/0x90         ctx_resched+0x68/0xb0         perf_event_exec+0x138/0x508         begin_new_exec+0x52c/0xd40         load_elf_binary+0x6b8/0x17d0         bprm_execve+0x360/0x7f8         do_execveat_common.isra.47+0x218/0x238
        __arm64_sys_execve+0x48/0x60         invoke_syscall+0x4c/0x110         el0_svc_common.constprop.4+0xfc/0x120         do_el0_svc+0x34/0xc0         el0_svc+0x40/0x98         el0t_64_sync_handler+0x98/0xc0         el0t_64_sync+0x170/0x174

    Fix the issue by removing the runtime PM calls completely. They are not     needed here because it must have already been done when building the     path for a trace.

    [ Fix build warnings ]

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

Note that Nessus has not tested for this issue 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.

  - In the Linux kernel, the following vulnerability has been resolved: coresight: cti: Fix hang in     cti_disable_hw() cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use     runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852     (Revert firmware: arm_scmi: Add clock management to the SCMI power domain), this causes a hang on Juno     when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was     also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit     692c9a499b28 (coresight: cti: Correct the parameter for pm_runtime_put) With lock and scheduler     debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent:
    20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151     in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected:
    0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at     (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>]     copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948     softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted     6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development     Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58     dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88
    __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150     coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70     event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0     ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508     begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8     do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110     el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98     el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls     completely. They are not needed here because it must have already been done when building the path for a     trace. [ Fix build warnings ] (CVE-2022-50491)

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

An update of the linux package has been released.

ID	Name	Product	Family	Type	Severity
360748	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1779987841)	Nessus	Alma Linux Local Security Checks	Local	high
308629	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-011125)	Nessus	Unity Linux Local Security Checks	Local	medium
308241	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-006926)	Nessus	Unity Linux Local Security Checks	Local	medium
269344	Linux Distros Unpatched Vulnerability : CVE-2022-50491	Nessus	Misc.	Local	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2022-50491

medium

Tenable Plugins

high

medium

medium

medium

high