In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix race during abort for file descriptors fput() doesn't actually call file_operations release() synchronously, it puts the file on a work queue and it will be released eventually. This is normally fine, except for iommufd the file and the iommufd_object are tied to gether. The file has the object as it's private_data and holds a users refcount, while the object is expected to remain alive as long as the file is. When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount. Fix this by putting the core code in charge of the file lifetime, and call __fput_sync() during abort to ensure that release() is called before kfree. __fput_sync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle. If the object is successfully allocated then the file will hold a users refcount and the iommufd_object cannot be destroyed. It is worth noting that close(); ioctl(IOMMU_DESTROY); doesn't have an issue because close() is already using a synchronous version of fput(). The UAF looks like this: BUG: KASAN: slab-use-after-free in iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164 CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline] __refcount_dec include/linux/refcount.h:455 [inline] refcount_dec include/linux/refcount.h:476 [inline] iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 __fput+0x402/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f

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

  - An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to     obtain sensitive information from heap memory via crafted frame lengths from a device. (CVE-2022-26966)

  - In the Linux kernel, the following vulnerability has been resolved: kprobes: don't call disarm_kprobe()     for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already     disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to     /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this     time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat     /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes     kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 >     /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r
    __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill     execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE()     in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice,     and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table.
    Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
    aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the     infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list :
    show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop :
    warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue,     make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at
    __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130
    __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm:
    execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP:
    0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75     d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89     c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5     RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
    0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00     R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe     (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe     (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)     perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)     perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971)     perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput     (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

  - In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write     on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace     action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params'     is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array     'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is     TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than     16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the     issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-     of-bound write. [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1; int v2; int v3; int v4; int     v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int     v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28;
    int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int     v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51;
    int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int     v63 >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \     events/sched/sched_waking/trigger # echo hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid) >> events/sched/sched_switch/trigger [2] BUG: unable to handle page     fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),     BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2     44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84     d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48     EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010     RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09:
    0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538     R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)     knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3:
    0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> __find_event_file+0x55/0x90     action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0     trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160     ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb     bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0     ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX:
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143     RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

  - In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error     handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in     scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative     WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows     for the early termination of problematic sessions. Previously, sessions were only released at the end of     j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 &     while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0     18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller     to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit     ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue     is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of     sungem driver, however, disable_irq() might sleep. After analyzing the implementation of     fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX     completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so     fec_poll_controller() can be safely removed. (CVE-2024-38553)

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

  - An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to     obtain sensitive information from heap memory via crafted frame lengths from a device. (CVE-2022-26966)

  - In the Linux kernel, the following vulnerability has been resolved: kprobes: don't call disarm_kprobe()     for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already     disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to     /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this     time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat     /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes     kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 >     /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r
    __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill     execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE()     in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice,     and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table.
    Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
    aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the     infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list :
    show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop :
    warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue,     make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at
    __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130
    __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm:
    execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP:
    0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75     d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89     c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5     RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
    0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00     R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe     (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe     (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)     perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)     perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971)     perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput     (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

  - In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write     on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace     action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params'     is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array     'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is     TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than     16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the     issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-     of-bound write. [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1; int v2; int v3; int v4; int     v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int     v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28;
    int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int     v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51;
    int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int     v63 >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \     events/sched/sched_waking/trigger # echo hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\     pid,pid,pid,pid,pid,pid,pid,pid,pid) >> events/sched/sched_switch/trigger [2] BUG: unable to handle page     fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),     BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2     44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84     d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48     EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010     RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09:
    0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538     R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)     knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3:
    0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> __find_event_file+0x55/0x90     action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0     trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160     ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb     bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0     ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX:
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143     RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

  - In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error     handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in     scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative     WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows     for the early termination of problematic sessions. Previously, sessions were only released at the end of     j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 &     while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0     18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller     to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit     ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue     is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of     sungem driver, however, disable_irq() might sleep. After analyzing the implementation of     fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX     completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so     fec_poll_controller() can be safely removed. (CVE-2024-38553)

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 CIQ ciqsa-2026_1337 advisory.

    This advisory aggregates security fixes for the kernel SRPM in CIQ LTS 9.6. It addresses 16 CVEs:
    CVE-2026-23144, CVE-2025-38323, CVE-2025-39881, CVE-2025-38180, CVE-2025-38106, and 11 more.

Tenable has extracted the preceding description block directly from the CIQ 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 Rocky Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ crlsa-2025_23241 advisory.

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

Tenable has extracted the preceding description block directly from the CIQ 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 Rocky Linux 10.1 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ crlsa-2026_0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

Tenable has extracted the preceding description block directly from the CIQ 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 AlmaLinux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALSA-2026:0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)
      * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)
      * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)
      * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)
      * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)
      * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)
      * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)
      * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)
      * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

Tenable has extracted the preceding description block directly from the AlmaLinux 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 RockyLinux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RLSA-2026:0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

Tenable has extracted the preceding description block directly from the RockyLinux 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 Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:0453 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 MiracleLinux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the AXSA:2025-11625:100 advisory.

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)
      * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)
      * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

Tenable has extracted the preceding description block directly from the MiracleLinux 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 Oracle Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-0453 advisory.

    - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths (CKI Backport Bot)     [RHEL-137150] {CVE-2025-68287}
    - drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CKI Backport Bot) [RHEL-134431]     {CVE-2025-40277}
    - net: phylink: add lock for serializing concurrent pl->phydev writes with resolver (CKI Backport Bot)     [RHEL-129812] {CVE-2025-39905}
    - sctp: avoid NULL dereference when chunk data buffer is missing (CKI Backport Bot) [RHEL-134010]     {CVE-2025-40240}
    - HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CKI Backport Bot) [RHEL-124610]     {CVE-2025-39806}
    - audit: fix out-of-bounds read in audit_compare_dname_path() (Richard Guy Briggs) [RHEL-119185]     {CVE-2025-39840}
    - iommufd: Fix race during abort for file descriptors (Eder Zulian) [RHEL-123789] {CVE-2025-39966}
    - mm: slub: avoid wake up kswapd in set_track_prepare (Audra Mitchell) [RHEL-125522] {CVE-2025-39843}
    - tls: wait for pending async decryptions if tls_strp_msg_hold fails (CKI Backport Bot) [RHEL-128866]     {CVE-2025-40176}

Tenable has extracted the preceding description block directly from the Oracle Linux 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 AlmaLinux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALSA-2025:23241 advisory.

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)
      * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)
      * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

Tenable has extracted the preceding description block directly from the AlmaLinux 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 RockyLinux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RLSA-2025:23241 advisory.

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

Tenable has extracted the preceding description block directly from the RockyLinux 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 Oracle Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2025-23241 advisory.

    - CVE-2025-38499 kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (Abhi Das) [RHEL-129261] {CVE-2025-38499}
    - tls: wait for pending async decryptions if tls_strp_msg_hold fails (CKI Backport Bot) [RHEL-128860]     {CVE-2025-40176}

Tenable has extracted the preceding description block directly from the Oracle Linux 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 Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2025:23250 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: net: tun: Update napi->skb after XDP process (CVE-2025-39984)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2025:23241 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (CVE-2025-38499)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 Redhat Enterprise Linux 9 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2025:22802 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

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

  - iommufd: Fix race during abort for file descriptors fput() doesn't actually call file_operations release()     synchronously, it puts the file on a work queue and it will be released eventually. This is normally fine,     except for iommufd the file and the iommufd_object are tied to gether. The file has the object as it's     private_data and holds a users refcount, while the object is expected to remain alive as long as the file     is. When the allocation of a new object aborts before installing the file it will fput() the file and then     go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries     to decrement the users refcount. Fix this by putting the core code in charge of the file lifetime, and     call __fput_sync() during abort to ensure that release() is called before kfree. __fput_sync() is a bit     too tricky to open code in all the object implementations. Instead the objects tell the core code where     the file pointer is and the core will take care of the life cycle. If the object is successfully allocated     then the file will hold a users refcount and the iommufd_object cannot be destroyed. It is worth noting     that close(); ioctl(IOMMU_DESTROY); doesn't have an issue because close() is already using a synchronous     version of fput(). The UAF looks like this: BUG: KASAN: slab-use-after-free in     iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr     ffff888059c97804 by task syz.0.46/6164 CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0     PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025     Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0     lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630     mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 check_region_inline     mm/kasan/generic.c:183 [inline] kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189     instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_sub_release     include/linux/atomic/atomic-instrumented.h:400 [inline] __refcount_dec include/linux/refcount.h:455     [inline] refcount_dec include/linux/refcount.h:476 [inline] iommufd_eventq_fops_release+0x45/0xc0     drivers/iommu/iommufd/eventq.c:376 __fput+0x402/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240     kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]     exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-     entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]     syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0     arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2025-39966)

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

ID	Name	Product	Family	Type	Severity
361300	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1780562693)	Nessus	Alma Linux Local Security Checks	Local	high
361263	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1780562693)	Nessus	Rocky Linux Local Security Checks	Local	high
356656	Rocky Linux 9.6 [CIQ] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ciqsa-2026_1337)	Nessus	Rocky Linux Local Security Checks	Local	high
354758	Rocky Linux 9 [CIQ] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (crlsa-2025_23241)	Nessus	Rocky Linux Local Security Checks	Local	high
354138	Rocky Linux 10.1 [CIQ] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (crlsa-2026_0453)	Nessus	Rocky Linux Local Security Checks	Local	high
291602	AlmaLinux 10 : kernel (ALSA-2026:0453)	Nessus	Alma Linux Local Security Checks	Local	high
291297	RockyLinux 10 : kernel (RLSA-2026:0453)	Nessus	Rocky Linux Local Security Checks	Local	high
283499	RHEL 10 : kernel (RHSA-2026:0453)	Nessus	Red Hat Local Security Checks	Local	high
283169	MiracleLinux 9 : kernel-5.14.0-611.16.1.el9_7 (AXSA:2025-11625:100)	Nessus	Miracle Linux Local Security Checks	Local	high
282630	Oracle Linux 10 : kernel (ELSA-2026-0453)	Nessus	Oracle Linux Local Security Checks	Local	high
282336	AlmaLinux 9 : kernel (ALSA-2025:23241)	Nessus	Alma Linux Local Security Checks	Local	high
279628	RockyLinux 9 : kernel (RLSA-2025:23241)	Nessus	Rocky Linux Local Security Checks	Local	high
279383	Oracle Linux 9 : kernel (ELSA-2025-23241)	Nessus	Oracle Linux Local Security Checks	Local	high
278989	RHEL 10 : kernel (RHSA-2025:23250)	Nessus	Red Hat Local Security Checks	Local	high
278951	RHEL 9 : kernel (RHSA-2025:23241)	Nessus	Red Hat Local Security Checks	Local	high
277858	RHEL 9 : kernel (RHSA-2025:22802)	Nessus	Red Hat Local Security Checks	Local	high
271558	Linux Distros Unpatched Vulnerability : CVE-2025-39966	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2025-39966

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high