In the Linux kernel, the following vulnerability has been resolved: ntb_netdev: Use dev_kfree_skb_any() in interrupt context TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers.

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1778756832 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound     read in resp_readcap16() The following warning was observed running syzkaller: [ 3813.830724] sg_write:
    data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor     not setting count and/or reply_len properly [ 3813.836956]     ================================================================== [ 3813.839465] BUG: KASAN: stack-out-     of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task     syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524]     print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439]     check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0     [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [     3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203]     scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329]     scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544]     blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637]     sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [     3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841]     do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be     reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c,     &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff,     &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 =     syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB=00     000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff61     96a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d], 0x126) In resp_readcap16()     we get int alloc_len value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but     arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32.
    (CVE-2021-47191)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound     read in resp_report_tgtpgs() The following issue was observed running syzkaller: BUG: KASAN: slab-out-of-     bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in     sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-     executor.0/9815 CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware     name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack     lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118     print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352     [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy     include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831     fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770     drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429     scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0     drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
    __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484     blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0     drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0     drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c     vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599     do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe We get     'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'.
    Switch n, alen, and rlen to u32. (CVE-2021-47219)

  - In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks     from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical     address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct     kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva =     slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the     boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such     a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first     retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within     the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and     continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-     of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this     is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent     on the first. Right now it's not clear if there are any cases in which this is exploitable. One     interesting case was reported by the original author of this patch, and involves visiting guest page     tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which     contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask     kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the     VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and     would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively     protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks     speculation of invalid hvas. Sean Christopherson noted that this patch does not cover     kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and     therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.
    (CVE-2021-47277)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: make apf token non-zero     to fix bug In current async pagefault logic, when a page is ready, KVM relies on     kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This     function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when     a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can     deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is     confused with previous mention and may lead the loss of this READY event. This bug may cause task blocked     forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 echo     0 > /proc/sys/kernel/hung_task_timeout_secs disables this message. task:stress state:D stack: 0 pid: 7532     ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0     kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70
    __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ?     asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500     EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011     RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09:
    0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002     R14: 000000000007d000 R15: 0000000000001000 (CVE-2022-48943)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: addrlabel: fix infoleak when     sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network,
    __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-     infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit     ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one     net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350     net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb     net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325     netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263     netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50     net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80     net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628     rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at:
    slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398
    __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954
    __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437
    __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new     ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608     rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550     net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel     net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345     netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field     is always initialized. (CVE-2022-49865)

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

  - In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing     m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of     m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by     m_can_class_allocate_dev(), otherwise there will be memleak. (CVE-2022-49024)

  - 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: usbnet: fix memory leak in error case     usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag     v3: fix uninitialized buf pointer (CVE-2022-49657)

  - In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix     missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created     skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This     patch initializes the 8 byte CAN header with zero. (CVE-2022-49845)

  - In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak     in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of     kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev     after calling device_register(), even if it returned an error! Always use put_device() to give up the     reference initialized. (CVE-2022-50349)

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

  - In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing     m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of     m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by     m_can_class_allocate_dev(), otherwise there will be memleak. (CVE-2022-49024)

  - 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: usbnet: fix memory leak in error case     usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag     v3: fix uninitialized buf pointer (CVE-2022-49657)

  - In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix     missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created     skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This     patch initializes the 8 byte CAN header with zero. (CVE-2022-49845)

  - In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak     in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of     kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev     after calling device_register(), even if it returned an error! Always use put_device() to give up the     reference initialized. (CVE-2022-50349)

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

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

    ntb_netdev: Use dev_kfree_skb_any() in interrupt context

    TX/RX callback handlers (ntb_netdev_tx_handler(),     ntb_netdev_rx_handler()) can be called in interrupt     context via the DMA framework when the respective     DMA operations have completed. As such, any calls     by these routines to free skb's, should use the     interrupt context safe dev_kfree_skb_any() function.

    Previously, these callback handlers would call the     interrupt unsafe version of dev_kfree_skb(). This has     not presented an issue on Intel IOAT DMA engines as     that driver utilizes tasklets rather than a hard     interrupt handler, like the AMD PTDMA DMA driver.
    On AMD systems, a kernel WARNING message is     encountered, which is being issued from     skb_release_head_state() due to in_hardirq()     being true.

    Besides the user visible WARNING from the kernel,     the other symptom of this bug was that TCP/IP performance     across the ntb_netdev interface was very poor, i.e.
    approximately an order of magnitude below what was     expected. With the repair to use dev_kfree_skb_any(),     kernel WARNINGs from skb_release_head_state() ceased     and TCP/IP performance, as measured by iperf, was on     par with expected results, approximately 20 Gb/s on     AMD Milan based server. Note that this performance     is comparable with Intel based servers.

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

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

    ntb_netdev: Use dev_kfree_skb_any() in interrupt context

    TX/RX callback handlers (ntb_netdev_tx_handler(),     ntb_netdev_rx_handler()) can be called in interrupt     context via the DMA framework when the respective     DMA operations have completed. As such, any calls     by these routines to free skb's, should use the     interrupt context safe dev_kfree_skb_any() function.

    Previously, these callback handlers would call the     interrupt unsafe version of dev_kfree_skb(). This has     not presented an issue on Intel IOAT DMA engines as     that driver utilizes tasklets rather than a hard     interrupt handler, like the AMD PTDMA DMA driver.
    On AMD systems, a kernel WARNING message is     encountered, which is being issued from     skb_release_head_state() due to in_hardirq()     being true.

    Besides the user visible WARNING from the kernel,     the other symptom of this bug was that TCP/IP performance     across the ntb_netdev interface was very poor, i.e.
    approximately an order of magnitude below what was     expected. With the repair to use dev_kfree_skb_any(),     kernel WARNINGs from skb_release_head_state() ceased     and TCP/IP performance, as measured by iperf, was on     par with expected results, approximately 20 Gb/s on     AMD Milan based server. Note that this performance     is comparable with Intel based servers.

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

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

    ntb_netdev: Use dev_kfree_skb_any() in interrupt context

    TX/RX callback handlers (ntb_netdev_tx_handler(),     ntb_netdev_rx_handler()) can be called in interrupt     context via the DMA framework when the respective     DMA operations have completed. As such, any calls     by these routines to free skb's, should use the     interrupt context safe dev_kfree_skb_any() function.

    Previously, these callback handlers would call the     interrupt unsafe version of dev_kfree_skb(). This has     not presented an issue on Intel IOAT DMA engines as     that driver utilizes tasklets rather than a hard     interrupt handler, like the AMD PTDMA DMA driver.
    On AMD systems, a kernel WARNING message is     encountered, which is being issued from     skb_release_head_state() due to in_hardirq()     being true.

    Besides the user visible WARNING from the kernel,     the other symptom of this bug was that TCP/IP performance     across the ntb_netdev interface was very poor, i.e.
    approximately an order of magnitude below what was     expected. With the repair to use dev_kfree_skb_any(),     kernel WARNINGs from skb_release_head_state() ceased     and TCP/IP performance, as measured by iperf, was on     par with expected results, approximately 20 Gb/s on     AMD Milan based server. Note that this performance     is comparable with Intel based servers.

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

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

    ntb_netdev: Use dev_kfree_skb_any() in interrupt context

    TX/RX callback handlers (ntb_netdev_tx_handler(),     ntb_netdev_rx_handler()) can be called in interrupt     context via the DMA framework when the respective     DMA operations have completed. As such, any calls     by these routines to free skb's, should use the     interrupt context safe dev_kfree_skb_any() function.

    Previously, these callback handlers would call the     interrupt unsafe version of dev_kfree_skb(). This has     not presented an issue on Intel IOAT DMA engines as     that driver utilizes tasklets rather than a hard     interrupt handler, like the AMD PTDMA DMA driver.
    On AMD systems, a kernel WARNING message is     encountered, which is being issued from     skb_release_head_state() due to in_hardirq()     being true.

    Besides the user visible WARNING from the kernel,     the other symptom of this bug was that TCP/IP performance     across the ntb_netdev interface was very poor, i.e.
    approximately an order of magnitude below what was     expected. With the repair to use dev_kfree_skb_any(),     kernel WARNINGs from skb_release_head_state() ceased     and TCP/IP performance, as measured by iperf, was on     par with expected results, approximately 20 Gb/s on     AMD Milan based server. Note that this performance     is comparable with Intel based servers.

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.

  - ntb_netdev: Use dev_kfree_skb_any() in interrupt context TX/RX callback handlers (ntb_netdev_tx_handler(),     ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA     operations have completed. As such, any calls by these routines to free skb's, should use the interrupt     context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt     unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that     driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD     systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due     to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this     bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order     of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from     skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected     results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with     Intel based servers. (CVE-2022-50476)

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
362062	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1778756832)	Nessus	CentOS Local Security Checks	Local	high
361976	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778787063)	Nessus	Rocky Linux Local Security Checks	Local	high
361904	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778787063)	Nessus	Alma Linux Local Security Checks	Local	high
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
342482	Unity Linux 20.1070-8ae / 20.1070e Security Update: kernel (UTSA-2026-105426)	Nessus	Unity Linux Local Security Checks	Local	medium
308852	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-011028)	Nessus	Unity Linux Local Security Checks	Local	medium
308276	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-006950)	Nessus	Unity Linux Local Security Checks	Local	medium
300888	Unity Linux 20.1070a Security Update: kernel (UTSA-2026-005730)	Nessus	Unity Linux Local Security Checks	Local	medium
269391	Linux Distros Unpatched Vulnerability : CVE-2022-50476	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-50476

medium

Tenable Plugins

high

high

high

high

medium

medium

medium

medium

medium

high