In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated---

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

  - In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register     read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware     that the relaxed variants are just normal loads and stores and this is causing problems like: [     210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529     dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6     nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI     CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G     E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [     210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [     210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [     210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [     210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811]     call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777]     run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [     210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857]     arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470]     cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [     210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption     when these were relaxed seems to be that device memory would be mapped non reordering, and that other     constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory     rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy,     but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they     were independent operations when in truth they are not, but the compiler can't know that. When looking at     the assembly dumps for many of these routines its possible to see very clean, but not strictly in program     order operations occurring as the compiler would be free to do if these weren't actually register     reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled     around but the device still seems unable to reliably send/receive data. A better plan is to use the safer     readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed     variants for performance reasons. I would suggest that any performance problems ---truncated---     (CVE-2022-49194)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in     isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached     with a compliant CAN ID address configuration. The provided address information consisted of CAN ID     0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the     SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - In the Linux kernel, the following vulnerability has been resolved: net/smc: Reset connection when trying     to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced     by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer     dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT     SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000     RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180     R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000)     GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000     DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>     ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK>     During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in     smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the     connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB     registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned     to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be     executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct     SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link     group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(),     conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related     MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign     existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in     SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB     creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept()     accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix     this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and     clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Cap MSIX used to online     CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the     kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver     tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the     MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106     irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ?     irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ?     ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ?     irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ?     auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0     bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa     [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50     do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ?     rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0     ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ?     selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ?     do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb     (CVE-2023-53811)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer     dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes     break the assumption of one transfer function always being available. Fix this by always checking the     pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical     regressions] (CVE-2024-35984)

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

  - In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register     read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware     that the relaxed variants are just normal loads and stores and this is causing problems like: [     210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529     dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6     nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI     CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G     E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [     210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [     210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [     210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [     210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811]     call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777]     run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [     210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857]     arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470]     cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [     210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption     when these were relaxed seems to be that device memory would be mapped non reordering, and that other     constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory     rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy,     but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they     were independent operations when in truth they are not, but the compiler can't know that. When looking at     the assembly dumps for many of these routines its possible to see very clean, but not strictly in program     order operations occurring as the compiler would be free to do if these weren't actually register     reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled     around but the device still seems unable to reliably send/receive data. A better plan is to use the safer     readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed     variants for performance reasons. I would suggest that any performance problems ---truncated---     (CVE-2022-49194)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in     isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached     with a compliant CAN ID address configuration. The provided address information consisted of CAN ID     0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the     SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - In the Linux kernel, the following vulnerability has been resolved: net/smc: Reset connection when trying     to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced     by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer     dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT     SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000     RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180     R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000)     GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000     DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>     ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK>     During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in     smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the     connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB     registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned     to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be     executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct     SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link     group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(),     conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related     MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign     existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in     SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB     creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept()     accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix     this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and     clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Cap MSIX used to online     CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the     kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver     tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the     MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106     irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ?     irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ?     ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ?     irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ?     auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0     bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa     [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50     do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ?     rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0     ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ?     selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ?     do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb     (CVE-2023-53811)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer     dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes     break the assumption of one transfer function always being available. Fix this by always checking the     pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical     regressions] (CVE-2024-35984)

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

  - In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length     underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic,     when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are     seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register     read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware     that the relaxed variants are just normal loads and stores and this is causing problems like: [     210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529     dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6     nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI     CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G     E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [     210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [     210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [     210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [     210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811]     call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777]     run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [     210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857]     arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470]     cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [     210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption     when these were relaxed seems to be that device memory would be mapped non reordering, and that other     constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory     rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy,     but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they     were independent operations when in truth they are not, but the compiler can't know that. When looking at     the assembly dumps for many of these routines its possible to see very clean, but not strictly in program     order operations occurring as the compiler would be free to do if these weren't actually register     reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled     around but the device still seems unable to reliably send/receive data. A better plan is to use the safer     readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed     variants for performance reasons. I would suggest that any performance problems ---truncated---     (CVE-2022-49194)

  - In the Linux kernel, the following vulnerability has been resolved: ima: Fix a potential integer overflow     in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be     negative, which may cause the integer overflow problem. (CVE-2022-49643)

  - In the Linux kernel, the following vulnerability has been resolved: ovl: Use buf flexible array for     memcpy() destination The buf flexible array needs to be the memcpy() destination to avoid false positive     run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93)     of single field &fh->fb at fs/overlayfs/export.c:799 (size 21) (CVE-2022-49743)

  - In the Linux kernel, the following vulnerability has been resolved: kprobes: Skip clearing aggrprobe's     post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe     has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the     aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to     disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with     kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free:
    Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at     kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5     PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0
    __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0     unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0     do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we     keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can     disarm it correctly. (CVE-2022-49779)

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

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

    net: bcmgenet: Use stronger register read/writes to assure ordering

    GCC12 appears to be much smarter about its dependency tracking and is     aware that the relaxed variants are just normal loads and stores and     this is causing problems like:

    [  210.074549] ------------[ cut here ]------------     [  210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out     [  210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240     [  210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet     nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]     [  210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110     [  210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E     5.17.0-rc7G12+ #58     [  210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters     [  210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022     [  210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)     [  210.161358] pc : dev_watchdog+0x234/0x240     [  210.161364] lr : dev_watchdog+0x234/0x240     [  210.161368] sp : ffff8000080a3a40     [  210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20     [  210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08     [  210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000     [  210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff     [  210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a     [  210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0     [  210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c     [  210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000     [  210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000     [  210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044     [  210.269682] Call trace:
    [  210.272133]  dev_watchdog+0x234/0x240     [  210.275811]  call_timer_fn+0x3c/0x15c     [  210.279489]  __run_timers.part.0+0x288/0x310     [  210.283777]  run_timer_softirq+0x48/0x80     [  210.287716]  __do_softirq+0x128/0x360     [  210.291392]  __irq_exit_rcu+0x138/0x140     [  210.295243]  irq_exit_rcu+0x1c/0x30     [  210.298745]  el1_interrupt+0x38/0x54     [  210.302334]  el1h_64_irq_handler+0x18/0x24     [  210.306445]  el1h_64_irq+0x7c/0x80     [  210.309857]  arch_cpu_idle+0x18/0x2c     [  210.313445]  default_idle_call+0x4c/0x140     [  210.317470]  cpuidle_idle_call+0x14c/0x1a0     [  210.321584]  do_idle+0xb0/0x100     [  210.324737]  cpu_startup_entry+0x30/0x8c     [  210.328675]  secondary_start_kernel+0xe4/0x110     [  210.333138]  __secondary_switched+0x94/0x98

    The assumption when these were relaxed seems to be that device memory     would be mapped non reordering, and that other constructs     (spinlocks/etc) would provide the barriers to assure that packet data     and in memory rings/queues were ordered with respect to device     register reads/writes. This itself seems a bit sketchy, but the real     problem with GCC12 is that it is moving the actual reads/writes around     at will as though they were independent operations when in truth they     are not, but the compiler can't know that. When looking at the     assembly dumps for many of these routines its possible to see very     clean, but not strictly in program order operations occurring as the     compiler would be free to do if these weren't actually register     reads/write operations.

    Its possible to suppress the timeout with a liberal bit of dma_mb()'s     sprinkled around but the device still seems unable to reliably     send/receive data. A better plan is to use the safer readl/writel     everywhere.

    Since this partially reverts an older commit, which notes the use of     the relaxed variants for performance reasons. I would suggest that     any performance problems
    ---truncated---

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-2025-988688 advisory.

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

    net: bcmgenet: Use stronger register read/writes to assure ordering

    GCC12 appears to be much smarter about its dependency tracking and is     aware that the relaxed variants are just normal loads and stores and     this is causing problems like:

    [  210.074549] ------------[ cut here ]------------     [  210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out     [  210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240     [  210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet     nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]     [  210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110     [  210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E     5.17.0-rc7G12+ #58     [  210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters     [  210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022     [  210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)     [  210.161358] pc : dev_watchdog+0x234/0x240     [  210.161364] lr : dev_watchdog+0x234/0x240     [  210.161368] sp : ffff8000080a3a40     [  210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20     [  210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08     [  210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000     [  210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff     [  210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a     [  210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0     [  210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c     [  210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000     [  210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000     [  210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044     [  210.269682] Call trace:
    [  210.272133]  dev_watchdog+0x234/0x240     [  210.275811]  call_timer_fn+0x3c/0x15c     [  210.279489]  __run_timers.part.0+0x288/0x310     [  210.283777]  run_timer_softirq+0x48/0x80     [  210.287716]  __do_softirq+0x128/0x360     [  210.291392]  __irq_exit_rcu+0x138/0x140     [  210.295243]  irq_exit_rcu+0x1c/0x30     [  210.298745]  el1_interrupt+0x38/0x54     [  210.302334]  el1h_64_irq_handler+0x18/0x24     [  210.306445]  el1h_64_irq+0x7c/0x80     [  210.309857]  arch_cpu_idle+0x18/0x2c     [  210.313445]  default_idle_call+0x4c/0x140     [  210.317470]  cpuidle_idle_call+0x14c/0x1a0     [  210.321584]  do_idle+0xb0/0x100     [  210.324737]  cpu_startup_entry+0x30/0x8c     [  210.328675]  secondary_start_kernel+0xe4/0x110     [  210.333138]  __secondary_switched+0x94/0x98

    The assumption when these were relaxed seems to be that device memory     would be mapped non reordering, and that other constructs     (spinlocks/etc) would provide the barriers to assure that packet data     and in memory rings/queues were ordered with respect to device     register reads/writes. This itself seems a bit sketchy, but the real     problem with GCC12 is that it is moving the actual reads/writes around     at will as though they were independent operations when in truth they     are not, but the compiler can't know that. When looking at the     assembly dumps for many of these routines its possible to see very     clean, but not strictly in program order operations occurring as the     compiler would be free to do if these weren't actually register     reads/write operations.

    Its possible to suppress the timeout with a liberal bit of dma_mb()'s     sprinkled around but the device still seems unable to reliably     send/receive data. A better plan is to use the safer readl/writel     everywhere.

    Since this partially reverts an older commit, which notes the use of     the relaxed variants for performance reasons. I would suggest that     any performance problems
    ---truncated---

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-2025-989592 advisory.

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

    net: bcmgenet: Use stronger register read/writes to assure ordering

    GCC12 appears to be much smarter about its dependency tracking and is     aware that the relaxed variants are just normal loads and stores and     this is causing problems like:

    [  210.074549] ------------[ cut here ]------------     [  210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out     [  210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240     [  210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet     nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]     [  210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110     [  210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E     5.17.0-rc7G12+ #58     [  210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters     [  210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS     EDK2-DEV 02/08/2022     [  210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)     [  210.161358] pc : dev_watchdog+0x234/0x240     [  210.161364] lr : dev_watchdog+0x234/0x240     [  210.161368] sp : ffff8000080a3a40     [  210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20     [  210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08     [  210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000     [  210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff     [  210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a     [  210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0     [  210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c     [  210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000     [  210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000     [  210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044     [  210.269682] Call trace:
    [  210.272133]  dev_watchdog+0x234/0x240     [  210.275811]  call_timer_fn+0x3c/0x15c     [  210.279489]  __run_timers.part.0+0x288/0x310     [  210.283777]  run_timer_softirq+0x48/0x80     [  210.287716]  __do_softirq+0x128/0x360     [  210.291392]  __irq_exit_rcu+0x138/0x140     [  210.295243]  irq_exit_rcu+0x1c/0x30     [  210.298745]  el1_interrupt+0x38/0x54     [  210.302334]  el1h_64_irq_handler+0x18/0x24     [  210.306445]  el1h_64_irq+0x7c/0x80     [  210.309857]  arch_cpu_idle+0x18/0x2c     [  210.313445]  default_idle_call+0x4c/0x140     [  210.317470]  cpuidle_idle_call+0x14c/0x1a0     [  210.321584]  do_idle+0xb0/0x100     [  210.324737]  cpu_startup_entry+0x30/0x8c     [  210.328675]  secondary_start_kernel+0xe4/0x110     [  210.333138]  __secondary_switched+0x94/0x98

    The assumption when these were relaxed seems to be that device memory     would be mapped non reordering, and that other constructs     (spinlocks/etc) would provide the barriers to assure that packet data     and in memory rings/queues were ordered with respect to device     register reads/writes. This itself seems a bit sketchy, but the real     problem with GCC12 is that it is moving the actual reads/writes around     at will as though they were independent operations when in truth they     are not, but the compiler can't know that. When looking at the     assembly dumps for many of these routines its possible to see very     clean, but not strictly in program order operations occurring as the     compiler would be free to do if these weren't actually register     reads/write operations.

    Its possible to suppress the timeout with a liberal bit of dma_mb()'s     sprinkled around but the device still seems unable to reliably     send/receive data. A better plan is to use the safer readl/writel     everywhere.

    Since this partially reverts an older commit, which notes the use of     the relaxed variants for performance reasons. I would suggest that     any performance problems
    ---truncated---

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 remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1241-1 advisory.

    The SUSE Linux Enterprise 15 SP5 kernel was updated to receive various security bugfixes.

    The following security bugs were fixed:

    - CVE-2022-49053: scsi: target: tcmu: Fix possible page UAF (bsc#1237918).
    - CVE-2022-49465: blk-throttle: Set BIO_THROTTLED when bio has been throttled (bsc#1238919).
    - CVE-2022-49739: gfs2: Always check inode size of inline inodes (bsc#1240207).
    - CVE-2023-52935: mm/khugepaged: fix ->anon_vma race (bsc#1240276).
    - CVE-2024-53124: net: fix data-races around sk->sk_forward_alloc (bsc#1234074).
    - CVE-2024-53176: smb: During unmount, ensure all cached dir instances drop their dentry (bsc#1234894).
    - CVE-2024-53178: smb: Do not leak cfid when reconnect races with open_cached_dir (bsc#1234895).
    - CVE-2024-56651: can: hi311x: hi3110_can_ist(): fix potential use-after-free (bsc#1235528).
    - CVE-2024-57996: net_sched: sch_sfq: do not allow 1 packet limit (bsc#1239076).
    - CVE-2024-58013: Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync     (bsc#1239095).
    - CVE-2024-58014: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (bsc#1239109).
    - CVE-2025-21693: mm: zswap: properly synchronize freeing resources during CPU hotunplug (bsc#1237029).
    - CVE-2025-21718: net: rose: fix timer races against user threads (bsc#1239073).
    - CVE-2025-21772: partitions: mac: fix handling of bogus partition table (bsc#1238911).
    - CVE-2025-21780: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115).


Tenable has extracted the preceding description block directly from the SUSE 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 remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1027-1 advisory.

    The SUSE Linux Enterprise 15 SP4 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2024-2201: Fixed information leak in x86/BHI (bsc#1217339).
    - CVE-2024-41092: drm/i915/gt: Fix potential UAF by revoke of fence registers (bsc#1228483).
    - CVE-2024-42098: crypto: ecdh - explicitly zeroize private_key (bsc#1228779).
    - CVE-2024-42229: crypto: aead,cipher - zeroize key buffer after use (bsc#1228708).
    - CVE-2024-57996: net_sched: sch_sfq: do not allow 1 packet limit (bsc#1239076).
    - CVE-2024-58014: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (bsc#1239109).
    - CVE-2025-21718: net: rose: fix timer races against user threads (bsc#1239073).
    - CVE-2025-21780: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115).


Tenable has extracted the preceding description block directly from the SUSE 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.

  - net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about     its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this     is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV     WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at     net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E)     nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject     nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927]     CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC     Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi     Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate:
    80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [     210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29:
    ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25:
    0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21:
    ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [     210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14:
    2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10:
    ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 :
    0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [     210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [     210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489]
    __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716]
    __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [     210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445]     el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [     210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737]     cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138]
    __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would     be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure     that packet data and in memory rings/queues were ordered with respect to device register reads/writes.
    This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual     reads/writes around at will as though they were independent operations when in truth they are not, but the     compiler can't know that. When looking at the assembly dumps for many of these routines its possible to     see very clean, but not strictly in program order operations occurring as the compiler would be free to do     if these weren't actually register reads/write operations. Its possible to suppress the timeout with a     liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive     data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older     commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any     performance problems ---truncated--- (CVE-2022-49194)

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
360243	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1783091784)	Nessus	Alma Linux Local Security Checks	Local	medium
360066	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1783091784)	Nessus	Rocky Linux Local Security Checks	Local	medium
353122	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1779375889)	Nessus	Alma Linux Local Security Checks	Local	high
305386	Unity Linux 20.1050e Security Update: kernel (UTSA-2026-006655)	Nessus	Unity Linux Local Security Checks	Local	medium
273295	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988688)	Nessus	Unity Linux Local Security Checks	Local	medium
273032	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-989592)	Nessus	Unity Linux Local Security Checks	Local	medium
234407	SUSE SLES15 : Security update for the Linux Kernel (SUSE-SU-2025:1241-1)	Nessus	SuSE Local Security Checks	Local	high
233410	SUSE SLES15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2025:1027-1)	Nessus	SuSE Local Security Checks	Local	high
225360	Linux Distros Unpatched Vulnerability : CVE-2022-49194	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-49194

medium

Tenable Plugins

medium

medium

high

medium

medium

medium

high

high

medium

high