In the Linux kernel, the following vulnerability has been resolved: dm: don't attempt to queue IO under RCU protection dm looks up the table for IO based on the request type, with an assumption that if the request is marked REQ_NOWAIT, it's fine to attempt to submit that IO while under RCU read lock protection. This is not OK, as REQ_NOWAIT just means that we should not be sleeping waiting on other IO, it does not mean that we can't potentially schedule. A simple test case demonstrates this quite nicely: int main(int argc, char *argv[]) { struct iovec iov; int fd; fd = open("/dev/dm-0", O_RDONLY | O_DIRECT); posix_memalign(&iov.iov_base, 4096, 4096); iov.iov_len = 4096; preadv2(fd, &iov, 1, 0, RWF_NOWAIT); return 0; } which will instantly spew: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x11d/0x1b0 __might_resched+0x3c3/0x5e0 ? preempt_count_sub+0x150/0x150 mempool_alloc+0x1e2/0x390 ? mempool_resize+0x7d0/0x7d0 ? lock_sync+0x190/0x190 ? lock_release+0x4b7/0x670 ? internal_get_user_pages_fast+0x868/0x2d40 bio_alloc_bioset+0x417/0x8c0 ? bvec_alloc+0x200/0x200 ? internal_get_user_pages_fast+0xb8c/0x2d40 bio_alloc_clone+0x53/0x100 dm_submit_bio+0x27f/0x1a20 ? lock_release+0x4b7/0x670 ? blk_try_enter_queue+0x1a0/0x4d0 ? dm_dax_direct_access+0x260/0x260 ? rcu_is_watching+0x12/0xb0 ? blk_try_enter_queue+0x1cc/0x4d0 __submit_bio+0x239/0x310 ? __bio_queue_enter+0x700/0x700 ? kvm_clock_get_cycles+0x40/0x60 ? ktime_get+0x285/0x470 submit_bio_noacct_nocheck+0x4d9/0xb80 ? should_fail_request+0x80/0x80 ? preempt_count_sub+0x150/0x150 ? lock_release+0x4b7/0x670 ? __bio_add_page+0x143/0x2d0 ? iov_iter_revert+0x27/0x360 submit_bio_noacct+0x53e/0x1b30 submit_bio_wait+0x10a/0x230 ? submit_bio_wait_endio+0x40/0x40 __blkdev_direct_IO_simple+0x4f8/0x780 ? blkdev_bio_end_io+0x4c0/0x4c0 ? stack_trace_save+0x90/0xc0 ? __bio_clone+0x3c0/0x3c0 ? lock_release+0x4b7/0x670 ? lock_sync+0x190/0x190 ? atime_needs_update+0x3bf/0x7e0 ? timestamp_truncate+0x21b/0x2d0 ? inode_owner_or_capable+0x240/0x240 blkdev_direct_IO.part.0+0x84a/0x1810 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 ? blkdev_read_iter+0x40d/0x530 ? reacquire_held_locks+0x4e0/0x4e0 ? __blkdev_direct_IO_simple+0x780/0x780 ? rcu_is_watching+0x12/0xb0 ? __mark_inode_dirty+0x297/0xd50 ? preempt_count_add+0x72/0x140 blkdev_read_iter+0x2a4/0x530 do_iter_readv_writev+0x2f2/0x3c0 ? generic_copy_file_range+0x1d0/0x1d0 ? fsnotify_perm.part.0+0x25d/0x630 ? security_file_permission+0xd8/0x100 do_iter_read+0x31b/0x880 ? import_iovec+0x10b/0x140 vfs_readv+0x12d/0x1a0 ? vfs_iter_read+0xb0/0xb0 ? rcu_is_watching+0x12/0xb0 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 do_preadv+0x1b3/0x260 ? do_readv+0x370/0x370 __x64_sys_preadv2+0xef/0x150 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f5af41ad806 Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55 RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806 RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003 RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001 </TASK> where in fact it is ---truncated---

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: dm: don't attempt to queue IO under
    RCU protection dm looks up the table for IO based on the request type, with an assumption that if the
    request is marked REQ_NOWAIT, it's fine to attempt to submit that IO while under RCU read lock protection.
    This is not OK, as REQ_NOWAIT just means that we should not be sleeping waiting on other IO, it does not
    mean that we can't potentially schedule. A simple test case demonstrates this quite nicely: int main(int
    argc, char *argv[]) { struct iovec iov; int fd; fd = open("/dev/dm-0", O_RDONLY | O_DIRECT);
    posix_memalign(&iov.iov_base, 4096, 4096); iov.iov_len = 4096; preadv2(fd, &iov, 1, 0, RWF_NOWAIT); return
    0; } which will instantly spew: BUG: sleeping function called from invalid context at
    include/linux/sched/mm.h:306 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait
    preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 7 PID: 5580
    Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132 Hardware name: QEMU Standard PC (i440FX + PIIX,
    1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x11d/0x1b0
    __might_resched+0x3c3/0x5e0 ? preempt_count_sub+0x150/0x150 mempool_alloc+0x1e2/0x390 ?
    mempool_resize+0x7d0/0x7d0 ? lock_sync+0x190/0x190 ? lock_release+0x4b7/0x670 ?
    internal_get_user_pages_fast+0x868/0x2d40 bio_alloc_bioset+0x417/0x8c0 ? bvec_alloc+0x200/0x200 ?
    internal_get_user_pages_fast+0xb8c/0x2d40 bio_alloc_clone+0x53/0x100 dm_submit_bio+0x27f/0x1a20 ?
    lock_release+0x4b7/0x670 ? blk_try_enter_queue+0x1a0/0x4d0 ? dm_dax_direct_access+0x260/0x260 ?
    rcu_is_watching+0x12/0xb0 ? blk_try_enter_queue+0x1cc/0x4d0 __submit_bio+0x239/0x310 ?
    __bio_queue_enter+0x700/0x700 ? kvm_clock_get_cycles+0x40/0x60 ? ktime_get+0x285/0x470
    submit_bio_noacct_nocheck+0x4d9/0xb80 ? should_fail_request+0x80/0x80 ? preempt_count_sub+0x150/0x150 ?
    lock_release+0x4b7/0x670 ? __bio_add_page+0x143/0x2d0 ? iov_iter_revert+0x27/0x360
    submit_bio_noacct+0x53e/0x1b30 submit_bio_wait+0x10a/0x230 ? submit_bio_wait_endio+0x40/0x40
    __blkdev_direct_IO_simple+0x4f8/0x780 ? blkdev_bio_end_io+0x4c0/0x4c0 ? stack_trace_save+0x90/0xc0 ?
    __bio_clone+0x3c0/0x3c0 ? lock_release+0x4b7/0x670 ? lock_sync+0x190/0x190 ?
    atime_needs_update+0x3bf/0x7e0 ? timestamp_truncate+0x21b/0x2d0 ? inode_owner_or_capable+0x240/0x240
    blkdev_direct_IO.part.0+0x84a/0x1810 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 ?
    blkdev_read_iter+0x40d/0x530 ? reacquire_held_locks+0x4e0/0x4e0 ? __blkdev_direct_IO_simple+0x780/0x780 ?
    rcu_is_watching+0x12/0xb0 ? __mark_inode_dirty+0x297/0xd50 ? preempt_count_add+0x72/0x140
    blkdev_read_iter+0x2a4/0x530 do_iter_readv_writev+0x2f2/0x3c0 ? generic_copy_file_range+0x1d0/0x1d0 ?
    fsnotify_perm.part.0+0x25d/0x630 ? security_file_permission+0xd8/0x100 do_iter_read+0x31b/0x880 ?
    import_iovec+0x10b/0x140 vfs_readv+0x12d/0x1a0 ? vfs_iter_read+0xb0/0xb0 ? rcu_is_watching+0x12/0xb0 ?
    rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 do_preadv+0x1b3/0x260 ? do_readv+0x370/0x370
    __x64_sys_preadv2+0xef/0x150 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP:
    0033:0x7f5af41ad806 Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45
    89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d
    da 55 RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147 RAX: ffffffffffffffda RBX:
    0000000000000000 RCX: 00007f5af41ad806 RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003
    RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11:
    0000000000000246 R12: 0000000000000003 R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001
    </TASK> where in fact it is ---truncated--- (CVE-2023-53860)

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

    The SUSE Linux Enterprise 15 SP5 kernel was updated to fix various security issues

    The following security issues were fixed:

    - CVE-2022-50630: mm: hugetlb: fix UAF in hugetlb_handle_userfault (bsc#1254785).
    - CVE-2022-50700: wifi: ath10k: Delay the unmapping of the buffer (bsc#1255576).
    - CVE-2023-53254: cacheinfo: Fix shared_cpu_map to handle shared caches at different levels (bsc#1249871).
    - CVE-2023-53781: smc: Fix use-after-free in tcp_write_timer_handler() (bsc#1254751).
    - CVE-2024-56590: Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet (bsc#1235038).
    - CVE-2025-39977: futex: Prevent use-after-free during requeue-PI (bsc#1252046).
    - CVE-2025-40019: crypto: essiv - Check ssize for decryption and in-place encryption (bsc#1252678).
    - CVE-2025-40139: smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set() (bsc#1253409).
    - CVE-2025-40215: kABI: xfrm: delete x->tunnel as we delete x (bsc#1254959).
    - CVE-2025-40220: fuse: fix livelock in synchronous file put from fuseblk workers (bsc#1254520).
    - CVE-2025-40233: ocfs2: clear extent cache after moving/defragmenting extents (bsc#1254813).
    - CVE-2025-40258: mptcp: fix race condition in mptcp_schedule_work() (bsc#1254843).
    - CVE-2025-40277: drm/vmwgfx: Validate command header size against (bsc#1254894).
    - CVE-2025-40280: tipc: Fix use-after-free in tipc_mon_reinit_self() (bsc#1254847).
    - CVE-2025-40331: sctp: Prevent TOCTOU out-of-bounds write (bsc#1254615).
    - CVE-2025-68732: gpu: host1x: Fix race in syncpt alloc/free (bsc#1255688).

    The following non security issues were fixed:

    - ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids() (git-fixes).
    - ACPI: PRM: Remove unnecessary strict handler address checks (git-fixes).
    - ACPI: property: Do not pass NULL handles to acpi_attach_data() (git-fixes).
    - ACPI: property: Fix buffer properties extraction for subnodes (git-fixes).
    - KVM: SVM: Fix TSC_AUX virtualization setup (git-fixes).
    - RDMA/cm: Rate limit destroy CM ID timeout error message (git-fixes).
    - RDMA/counter: Check CAP_NET_RAW check in user namespace for RDMA counters (git-fixes).
    - RDMA/hns: Fix the modification of max_send_sge (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for anchor create (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for devx create (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create (git-fixes).
    - RDMA/mlx5: Fix compilation warning when USER_ACCESS isn't set (git-fixes).
    - RDMA/nldev: Check CAP_NET_RAW in user namespace for QP modify (git-fixes).
    - RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for QP create (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for RAW QP create (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create (git-fixes).
    - arch/idle: Change arch_cpu_idle() behavior: always exit with IRQs disabled (git-fixes).
    - cpuidle/poll: Ensure IRQs stay disabled after cpuidle_state::enter() calls (git-fixes).
    - cpuidle: Move IRQ state validation (git-fixes).
    - cpuidle: haltpoll: Do not enable interrupts when entering idle (git-fixes).
    - dm: free table mempools if not used in __bind (git-fixes).
    - padata: Honor the caller's alignment in case of chunk_size 0 (bsc#1237563).
    - platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL (git-fixes).
    - x86/bugs: Fix RSB clearing in indirect_branch_prediction_barrier() (git-fixes).
    - x86/bugs: Use SBPB in write_ibpb() if applicable (git-fixes).
    - x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT (git-fixes).
    - x86/tdx: Drop flags from __tdx_hypercall() (git-fixes).
    - x86/tdx: Dynamically disable SEPT violations from causing #VEs (git-fixes).
    - x86/tdx: Emit warning if IRQs are enabled during HLT #VE handling (git-fixes).
    - x86/tdx: Extend TDX_MODULE_CALL to support more TDCALL/SEAMCALL leafs (git-fixes).
    - x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed() (git-fixes).
    - x86/tdx: Fix arch_safe_halt() execution for TDX VMs (git-fixes).
    - x86/tdx: Introduce wrappers to read and write TD metadata (git-fixes).
    - x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE_CALL (git-fixes).
    - x86/tdx: Make macros of TDCALLs consistent with the spec (git-fixes).
    - x86/tdx: Pass TDCALL/SEAMCALL input/output registers via a structure (git-fixes).
    - x86/tdx: Reimplement __tdx_hypercall() using TDX_MODULE_CALL asm (git-fixes).
    - x86/tdx: Remove 'struct tdx_hypercall_args' (git-fixes).
    - x86/tdx: Remove TDX_HCALL_ISSUE_STI (git-fixes).
    - x86/tdx: Rename __tdx_module_call() to __tdcall() (git-fixes).
    - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup() (git-fixes).
    - x86/tdx: Retry partially-completed page conversion hypercalls (git-fixes).
    - x86/tdx: Skip saving output regs when SEAMCALL fails with VMFailInvalid (git-fixes).
    - x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro (git-fixes).
    - x86/virt/tdx: Make TDX_MODULE_CALL handle SEAMCALL #UD and #GP (git-fixes).
    - x86/virt/tdx: Wire up basic SEAMCALL functions (git-fixes).
    - xfs: fix sparse inode limits on runt AG (bsc#1254392).

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.

  - dm: don't attempt to queue IO under RCU protection dm looks up the table for IO based on the request type,     with an assumption that if the request is marked REQ_NOWAIT, it's fine to attempt to submit that IO while     under RCU read lock protection. This is not OK, as REQ_NOWAIT just means that we should not be sleeping     waiting on other IO, it does not mean that we can't potentially schedule. A simple test case demonstrates     this quite nicely: int main(int argc, char *argv[]) { struct iovec iov; int fd; fd = open(/dev/dm-0,     O_RDONLY | O_DIRECT); posix_memalign(&iov.iov_base, 4096, 4096); iov.iov_len = 4096; preadv2(fd, &iov, 1,     0, RWF_NOWAIT); return 0; } which will instantly spew: BUG: sleeping function called from invalid context     at include/linux/sched/mm.h:306 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-     nowait preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 7     PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132 Hardware name: QEMU Standard PC (i440FX     + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x11d/0x1b0
    __might_resched+0x3c3/0x5e0 ? preempt_count_sub+0x150/0x150 mempool_alloc+0x1e2/0x390 ?     mempool_resize+0x7d0/0x7d0 ? lock_sync+0x190/0x190 ? lock_release+0x4b7/0x670 ?     internal_get_user_pages_fast+0x868/0x2d40 bio_alloc_bioset+0x417/0x8c0 ? bvec_alloc+0x200/0x200 ?     internal_get_user_pages_fast+0xb8c/0x2d40 bio_alloc_clone+0x53/0x100 dm_submit_bio+0x27f/0x1a20 ?     lock_release+0x4b7/0x670 ? blk_try_enter_queue+0x1a0/0x4d0 ? dm_dax_direct_access+0x260/0x260 ?     rcu_is_watching+0x12/0xb0 ? blk_try_enter_queue+0x1cc/0x4d0 __submit_bio+0x239/0x310 ?
    __bio_queue_enter+0x700/0x700 ? kvm_clock_get_cycles+0x40/0x60 ? ktime_get+0x285/0x470     submit_bio_noacct_nocheck+0x4d9/0xb80 ? should_fail_request+0x80/0x80 ? preempt_count_sub+0x150/0x150 ?     lock_release+0x4b7/0x670 ? __bio_add_page+0x143/0x2d0 ? iov_iter_revert+0x27/0x360     submit_bio_noacct+0x53e/0x1b30 submit_bio_wait+0x10a/0x230 ? submit_bio_wait_endio+0x40/0x40
    __blkdev_direct_IO_simple+0x4f8/0x780 ? blkdev_bio_end_io+0x4c0/0x4c0 ? stack_trace_save+0x90/0xc0 ?
    __bio_clone+0x3c0/0x3c0 ? lock_release+0x4b7/0x670 ? lock_sync+0x190/0x190 ?     atime_needs_update+0x3bf/0x7e0 ? timestamp_truncate+0x21b/0x2d0 ? inode_owner_or_capable+0x240/0x240     blkdev_direct_IO.part.0+0x84a/0x1810 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 ?     blkdev_read_iter+0x40d/0x530 ? reacquire_held_locks+0x4e0/0x4e0 ? __blkdev_direct_IO_simple+0x780/0x780 ?     rcu_is_watching+0x12/0xb0 ? __mark_inode_dirty+0x297/0xd50 ? preempt_count_add+0x72/0x140     blkdev_read_iter+0x2a4/0x530 do_iter_readv_writev+0x2f2/0x3c0 ? generic_copy_file_range+0x1d0/0x1d0 ?     fsnotify_perm.part.0+0x25d/0x630 ? security_file_permission+0xd8/0x100 do_iter_read+0x31b/0x880 ?     import_iovec+0x10b/0x140 vfs_readv+0x12d/0x1a0 ? vfs_iter_read+0xb0/0xb0 ? rcu_is_watching+0x12/0xb0 ?     rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 do_preadv+0x1b3/0x260 ? do_readv+0x370/0x370
    __x64_sys_preadv2+0xef/0x150 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP:
    0033:0x7f5af41ad806 Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45     89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d     da 55 RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147 RAX: ffffffffffffffda RBX:
    0000000000000000 RCX: 00007f5af41ad806 RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003     RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11:
    0000000000000246 R12: 0000000000000003 R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001     </TASK> where in fact it is ---truncated--- (CVE-2023-53860)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2023-356 advisory.

    An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds     and crash in read_descriptors in drivers/usb/core/sysfs.c. (CVE-2023-37453)

    nftables out-of-bounds read in nf_osf_match_one() (CVE-2023-39189)

    A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the     fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds     read by setting the size fields with a value beyond the array boundaries, leading to a crash or     information disclosure. (CVE-2023-39192)

    A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the     flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds     read, leading to a crash or information disclosure. (CVE-2023-39193)

    An integer overflow in kmalloc_reserve() in the Linux kernel may allow a local user to crash the system,     or in some cases obtain code execution in kernel space. (CVE-2023-42752)

    The upstream commit describes this issue as follows:

    The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong     `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to     slab out-of-bound access. (CVE-2023-42753)

    A flaw was found in rsvp_change(). The root cause is an slab-out-of-bound access, but since the offset to     the original pointer is an `unsign int` fully controlled by users, the behavior is usually a wild pointer     access. (CVE-2023-42755)

    An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel     before 6.5.3. A buffer size may not be adequate for frames larger than the MTU. (CVE-2023-45871)

    A use-after-free vulnerability in the Linux kernel's net/sched: sch_hfsc (HFSC qdisc traffic control)     component can be exploited to achieve local privilege escalation.

    If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing     curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in     update_vf(). This leaves a dangling pointer that can cause a use-after-free.

    We recommend upgrading past commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f. (CVE-2023-4623)

    A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to     achieve local privilege escalation.

    When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free     in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in     agg_dequeue().

    We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8. (CVE-2023-4921)

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

    netfilter: nftables: exthdr: fix 4-byte stack OOB write

    If priv->len is a multiple of 4, then dst[len / 4] can write pastthe destination array which leads to     stack corruption.

    This construct is necessary to clean the remainder of the registerin case ->len is NOT a multiple of the     register size, so make itconditional just like nft_payload.c does.

    The bug was added in 4.1 cycle and then copied/inherited whentcp/sctp and ip option support was added.

    Bug reported by Zero Day Initiative project (ZDI-CAN-21950,ZDI-CAN-21951, ZDI-CAN-21961). (CVE-2023-52628)

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

    USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() (CVE-2023-52886)

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

    netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c     (CVE-2023-53179)

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

    af_unix: Fix data-races around user->unix_inflight. (CVE-2023-53204)

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

    KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state (CVE-2023-53208)

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

    md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() (CVE-2023-53210)

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

    drm/msm/mdp5: Don't leak some plane state (CVE-2023-53324)

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

    pstore/ram: Check start of empty przs during init (CVE-2023-53331)

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

    lwt: Fix return values of BPF xmit ops (CVE-2023-53338)

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

    skbuff: skb_segment, Call zero copy functions before using skbuff frags (CVE-2023-53354)

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

    tracing: Fix race issue between cpu buffer write and swap (CVE-2023-53368)

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

    ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer (CVE-2023-53395)

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

    xsk: Fix xsk_diag use-after-free error during socket cleanup (CVE-2023-53426)

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

    x86/MCE: Always save CS register on AMD Zen IF Poison errors (CVE-2023-53438)

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

    HID: multitouch: Correct devm device reference for hidinput input_dev name (CVE-2023-53454)

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

    scsi: qla4xxx: Add length check when parsing nlattrs (CVE-2023-53456)

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

    hsr: Fix uninit-value access in fill_frame_info() (CVE-2023-53462)

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

    kobject: Add sanity check for kset->kobj.ktype in kset_register() (CVE-2023-53480)

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

    iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind (CVE-2023-53501)

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

    PM / devfreq: Fix leak in devfreq_dev_release() (CVE-2023-53518)

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

    jbd2: check 'jh->b_transaction' before removing it from checkpoint (CVE-2023-53526)

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

    null_blk: fix poll request timeout handling (CVE-2023-53531)

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

    drm/i915: mark requests for GuC virtual engines to avoid use-after-free (CVE-2023-53552)

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

    bpf: reject unhashed sockets in bpf_sk_assign (CVE-2023-53585)

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

    drivers: base: Free devm resources when unregistering a device (CVE-2023-53596)

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

    Drivers: hv: vmbus: Don't dereference ACPI root object handle (CVE-2023-53647)

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

    perf trace: Really free the evsel->priv area (CVE-2023-53649)

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

    ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} (CVE-2023-53662)

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

    KVM: nSVM: Check instead of asserting on nested TSC scaling support (CVE-2023-53663)

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

    btrfs: output extra debug info if we failed to find an inline backref (CVE-2023-53672)

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

    scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show() (CVE-2023-53676)

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

    NFS: Fix a potential data corruption (CVE-2023-53711)

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

    md: raid1: fix potential OOB in raid1_remove_disk() (CVE-2023-53722)

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

    arm64: csum: Fix OoB access in IP checksum code for negative lengths (CVE-2023-53726)

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

    net/sched: fq_pie: avoid stalls in fq_pie_timer() (CVE-2023-53727)

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

    PCI: Free released resource after coalescing (CVE-2023-53743)

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

    net: deal with integer overflows in kmalloc_reserve() (CVE-2023-53752)

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

    crypto: api - Use work queue in crypto_destroy_instance (CVE-2023-53799)

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

    crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui() (CVE-2023-53817)

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

    kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg(). (CVE-2023-53825)

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

    net: read sk->sk_family once in sk_mc_loop() (CVE-2023-53831)

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

    bpf, sockmap: Fix skb refcnt race after locking changes (CVE-2023-53836)

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

    md/raid5-cache: fix a deadlock in r5l_exit_log() (CVE-2023-53848)

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

    of: overlay: Call of_changeset_init() early (CVE-2023-53856)

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

    dm: don't attempt to queue IO under RCU protection (CVE-2023-53860)

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

    ext4: correct grp validation in ext4_mb_good_group (CVE-2023-53861)

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

    net: ipv4: fix one memleak in __inet_del_ifa() (CVE-2023-53995)

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

    x86/sev: Make enc_dec_hypercall() accept a size instead of npages (CVE-2023-53996)

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

    af_unix: Fix data-race around unix_tot_inflight. (CVE-2023-54006)

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

    audit: fix possible soft lockup in __audit_inode_child() (CVE-2023-54045)

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

    kcm: Fix memory leak in error path of kcm_sendmsg() (CVE-2023-54112)

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

    rcu: dump vmalloc memory info safely (CVE-2023-54113)

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

    s390/dcssblk: fix kernel crash with list_add corruption (CVE-2023-54117)

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

    autofs: fix memory leak of waitqueues in autofs_catatonic_mode (CVE-2023-54134)

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

    vfio/type1: fix cap_migration information leak (CVE-2023-54137)

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

    scsi: target: core: Fix target_cmd_counter leak (CVE-2023-54154)

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

    of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name() (CVE-2023-54178)

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

    bpf: Fix issue in verifying allow_ptr_leaks (CVE-2023-54181)

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

    btrfs: fix lockdep splat and potential deadlock after failure running delayed items (CVE-2023-54224)

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

    amba: bus: fix refcount leak (CVE-2023-54230)

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

    btrfs: set page extent mapped after read_folio in relocate_one_page (CVE-2023-54253)

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

    btrfs: release path before inode lookup during the ino lookup ioctl (CVE-2023-54281)

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

    KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration (CVE-2023-54296)

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

    usb: typec: bus: verify partner exists in typec_altmode_attention (CVE-2023-54299)

    A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm     scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific     socket configuration, which could allow a local user to crash the system or escalate their privileges on     the system. (CVE-2023-6176)

Tenable has extracted the preceding description block directly from the tested product security advisory.

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

ID	Name	Product	Family	Type	Severity
451498	Google: sys-kernel/lakitu-kernel-6_1: security update to 17935.0.0	Tenable Cloud Security	Google COS Security Checks	Local	high
451498	Google: sys-kernel/lakitu-kernel-6_1: security update to 17935.0.0	Tenable Self-Hosted Container Security	Google COS 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
297194	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:0315-1)	Nessus	SuSE Local Security Checks	Local	high
297191	SUSE SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:0317-1)	Nessus	SuSE Local Security Checks	Local	high
296680	SUSE SLES15 / openSUSE 15 : Security update for the Linux Kernel (SUSE-SU-2026:0293-1)	Nessus	SuSE Local Security Checks	Local	high
296676	SUSE SLES15: kernel-azure / kernel-azure-devel / kernel-devel-azure / etc (SUSE-SU-2026:0281-1)	Nessus	SuSE Local Security Checks	Local	high
296481	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	Local	high
278010	Linux Distros Unpatched Vulnerability : CVE-2023-53860	Nessus	Misc.	Local	high
182458	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2023-356)	Nessus	Amazon Linux Local Security Checks	Local	high

Detections

Analytics

CVE-2023-53860

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high