Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - ALSA:usb-audio:Scarlett2 ミキサーインターフェイスの解析時にエンドポイント番号をチェックします。USB オーディオドライバーの Scarlett2 ミキサー quirk は、無効な形式の USB 記述子が渡される際に、NULL デリファレンスにヒットする可能性があります。これは、fuzzer により報告されているように、scarlett2_find_fc_interface() の解析されたインターフェイスにエンドポイントが存在することを前提とするためです。NULL 逆参照を回避するには、単に bNumEndpoints のサニティチェックを追加し、無効なインターフェイスをスキップします。(CVE-2026-43436)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

Rocky Linuxの 9.6 ホストには、TuxCare ALMALINUX9.6:CLSA-2026:1780562693アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 5.16.12より前の Linux カーネルで問題が発見されました。drivers/net/usb/sr9700.c では、攻撃者がデバイスから細工されたフレーム長を介してヒープメモリから機密情報を取得する可能性があります。(CVE-2022-26966)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

AlmaLinux 9.6 ホストには、TuxCare ALMALINUX9.6:CLSA-2026:1780562693アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 5.16.12より前の Linux カーネルで問題が発見されました。drivers/net/usb/sr9700.c では、攻撃者がデバイスから細工されたフレーム長を介してヒープメモリから機密情報を取得する可能性があります。(CVE-2022-26966)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2026:1783362244アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
    Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) (CVE-2022-49308)

  - Linux カーネルでは、以下の脆弱性が解決されています: tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
    Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
    vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
    __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)

  - Linux カーネルでは、以下の脆弱性が解決されています: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)

  - Linux カーネルでは、以下の脆弱性が解決されています: bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
    [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)

  - Linux カーネルでは、以下の脆弱性が解決されています: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
    *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートの Oracle Linux 10 / 9 ホストに、ELSA-2026-50372 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

    - net/sched: ページキャッシュ破損を引き起こす pedit の部分的な COW を修正 (Rajat Gupta) {CVE-2026-46331}
    - eventpoll: ep_remove struct eventpoll / struct file UAF を修正 (Christian Brauner) [Orabug: 39668743] {CVE-2026-46242}
    - net: skbuff: pskb_carve ヘルパーの zerocopy 参照の欠落を修正 (Minh Nguyen) [Orabug: 39656679] {CVE-2026-52943}
    - arm64: errata: さまざまな Arm CPU で TLBI エラータを緩和 (Mark Rutland) [Orabug: 39548792] {CVE-2025-10263}
    - openvswitch: vport:トンネルポートのリリースにおけるセルフデッドロックを修正 (Ilya Maximets) {CVE-2026-46165}
    - iommu/amd: 同時 TLB 無効化でのシーケンス割り当てをシリアル化 (Ankit Soni) {CVE-2026-43220}
    - usb: ulpi: ulpi_register() エラーパスのメモリ漏洩を修正 (Felix Gu) {CVE-2026-46109}
    - smb: client: ユーザー空間 cifs.spnego の説明を拒否 (Asim Viladi Oglu Manizada) [Orabug: 39463671] {CVE-2026-46243}
    - net: skbuff: frag-transfer ヘルパーを通じて共有フラグマーカーを伝播 (Hyunwoo Kim) [Orabug:
    39368826,39441323] {CVE-2026-43503,CVE-2026-46300}
    - net: skbuff: 合体中に共有フラグマーカーを維持 (William Bowling) [Orabug: 39368826] {CVE-2026-46300}
    - netfilter: nft_bitwise のゼロシフトを拒否 (Kai Ma) [Orabug: 39452464] {CVE-2026-46101}
    - net: ipv6: seg6 および rpl lwtunnels の NOREF dst 使用を修正 (Andrea Mayer) [Orabug: 39452457] {CVE-2026-46099}
    - ALSA: caiaq: プローブ失敗時の usb_dev refcount 漏洩を修正 (Deepanshu Kartikey) [Orabug: 39452739] {CVE-2026-46048}
    - ipv6: rpl: 再圧縮 mac_len SRH が増大する際にヘッドルームを確保 (Greg Kroah-Hartman) [Orabug: 39426003] {CVE-2026-43501}
    - ALSA: caiaq: エラーパスに残る可能性のある ep1_in_urb を修正 (Takashi Iwai) [Orabug: 39452746] {CVE-2026-45992}
    - net: bonding: bond_xmit_broadcast() でのメモリ解放後使用 (Use-After-Free) を修正 (Xiang Mei) [Orabug: 39205989] {CVE-2026-31419}
    - crypto: authencesn - インスタンス作成中に短い ahash ダイジェストを拒否 (Yucheng Lu) [Orabug: 39452231] {CVE-2026-46033}
    - spi: デバイスセットアップ失敗時のリソース漏洩を修正 (Johan Hovold) [Orabug: 39452400] {CVE-2026-46083}
    - net: qrtr: ns: ノードの総数を制限 (Manivannan Sadhasivam) [Orabug: 39452123] {CVE-2026-46003}
    - net: bridge: RCU リーダーで安定した FDB dst スナップショットを使用 (Zhengchuan Liang) [Orabug: 39452411] {CVE-2026-46086}
    - net: qrtr: ns: ルックアップの最大数を制限 (Manivannan Sadhasivam) [Orabug: 39452207] {CVE-2026-46026}
    - net: qrtr: ns: ノードごとのサーバー登録数の上限を制限 (Manivannan Sadhasivam) [Orabug: 39410851] {CVE-2026-43491}
    - RDMA/mana_ib: RSS QP 破壊で RX ステアリングを無効にする (Long Li) [Orabug: 39452406] {CVE-2026-46084}
    - media: rc: igorplugusb: 一貫性のルールを守る (Oliver Neukum) [Orabug: 39452432] {CVE-2026-46091}
    - wifi: mwifiex: mwifiex_adapter_cleanup() の use-after-free を修正 (Daniel Hodges) [Orabug: 39452343] {CVE-2026-46069}
    - thermal: core: サーマルゾーンガバナーのクリーンアップ問題を修正 (Rafael J. Wysocki) [Orabug: 39452186] {CVE-2026-46021}
    - smb: client: cifsacl で書き換える前に DACL 全体を検証 (Michael Bommarito) [Orabug:
    39300611] {CVE-2026-31709}
    - scsi: sd: device_add(&disk_dev) が失敗する際に欠落している put_disk() を修正 (Yang Xiuwei) [Orabug: 39452100] {CVE-2026-45997}
    - rtmutex: remove_waiter() で current の代わりに waiter::task を使用 (Keenan Dong) [Orabug: 39425998] {CVE-2026-43499}
    - ceph: ハッシュ化されていない場合は d_add() 負の dentry のみ (Max Kellermann) [Orabug: 39452291] {CVE-2026-46052}
    - dm mirror: create_dirty_log() の整数オーバーフローを修正 (Junrui Luo) [Orabug: 39452196] {CVE-2026-46023}
    - Bluetooth: hci_event: SSP パスキーハンドラーの潜在的な UAF を修正 (Shuvam Pandey) [Orabug: 39452304] {CVE-2026-46056}
    - tcp:リスナー移行後に sk_data_ready() を呼び出す (Zhenzhong Wu) [Orabug: 39452159] {CVE-2026-46015}
    - inotify: fsnotify_add_inode_mark_locked() が失敗したときのウォッチカウント漏洩を修正 (Chia-Ming Chang) [Orabug:
    39452250] {CVE-2026-46040}
    - md/raid5: ジャーナルメタデータにアクセスする前にペイロードサイズを検証 (Junrui Luo) [Orabug: 39452349] {CVE-2026-46070}
    - md/raid5: retry_aligned_read() でのソフトロックアップを修正 (Chia-Ming Chang) [Orabug: 39452287] {CVE-2026-46051}
    - ext4: ext4_xattr_inode_dec_ref_all() に欠落している brelse() を修正 (Sohei Koyama) [Orabug: 39452269] {CVE-2026-46046}
    - ext4: 領域外アクセスを防ぐために check_xattrs() の境界チェックを修正 (Deepanshu Kartikey) [Orabug:
    39452442] {CVE-2026-46094}
    - io_uring/poll: ウェイクアップ競合で EOF がないマルチショット受信を修正 (Jens Axboe) {CVE-2026-23473}
    - KVM: nSVM: 未処理の VMMCALL が L1 によって傍受されない場合に #UD を上げる (Kevin Cheng) [Orabug: 39452372] {CVE-2026-46076}
    - KVM: SVM: if EFER.SVME=0 の場合、INVLPGA に #UD を注入 (Kevin Cheng) [Orabug: 39452394] {CVE-2026-46082}
    - KVM: nSVM: L2 の VMRUN 後に、キャッシュされた vmcb12 に割り込みシャドウを同期 (Yosry Ahmed) [Orabug: 39452061] {CVE-2026-45987}
    - xfs: xfs_alloc_buftarg() でのリソース漏洩を修正 (Haoxiang Li) [Orabug: 39452131] {CVE-2026-46005}
    - libceph: ceph_handle_auth_reply() における潜在的な null-ptr-deref を防ぐ (Raphael Zimmer) [Orabug: 
    39452201] {CVE-2026-46024}
    - ipv4: icmp: icmp_pointers を使用する前に返信タイプを検証 (Ruide Cao) [Orabug: 39452243] {CVE-2026-46037}
    - RDMA/rxe: rxe_rcv の payload_size() の前に pad および ICRC を検証する (Hkbinbin) [Orabug: 39452259] {CVE-2026-46043}
    - net: qrtr: ns: ctrl_cmd_bye() 中にノードを解放 (Manivannan Sadhasivam) [Orabug: 39452246] {CVE-2026-46038}
    - rxrpc: rxkad 暗号アンアラインメント処理を修正 (David Howells) [Orabug: 39452728] {CVE-2026-46085}
    - ALSA: caiaq: プローブエラーを適切に処理 (Takashi Iwai) [Orabug: 39452126] {CVE-2026-46004}
    - rbd: プローブエラーを適切に処理 (Dawei Feng) [Orabug: 39452385] {CVE-2026-46079}
    - md/raid10: チェック操作および nowait リクエストのデッドロックを修正 (Josh Hunt) [Orabug: 39452284] {CVE-2026-46050}
    - jbd2: jbd2_journal_cancel_revoke() のデッドロックを修正 (Zhang Yi) [Orabug: 39452318] {CVE-2026-46061}
    - erofs: trailing dirents の領域外 nameoff 処理を修正 (Gao Xiang) [Orabug: 39452380] {CVE-2026-46078}
    - ALSA: ctxfi: S/PDIF のデフォルト RSR にフォールバックを追加 (Harin Lee) [Orabug: 39452280] {CVE-2026-46049}
    - ext2: ext2_iget() のゼロ i_nlink で有効なモードの inode を拒否 (Vasiliy Kovalev) [Orabug: 39452119] {CVE-2026-46002}
    - net: qrtr: ns: ドライバーの remove() の use-after-free を修正 (Manivannan Sadhasivam) [Orabug: 39452274] {CVE-2026-46047}
    - net: strparser: strp_abort_strp() の skb_head 漏洩を修正 (Luxiao Xu) [Orabug: 39452468] {CVE-2026-46102}
    - ALSA: control: snd_ctl_elem_init_enum_names() の strnlen() の前に buf_len を検証 (Ziqing Chen) [Orabug: 39452416] {CVE-2026-46088}
    - crypto: pcrypt - MAY_BACKLOG リクエストの処理を修正 (Herbert Xu) [Orabug: 39410863] {CVE-2026-43493}
    - wifi: rtw88: PCI Upstream ブリッジの有無をチェック (Fedor Pchelkin) [Orabug: 39452437] {CVE-2026-46092}
    - zram: 部分的破棄リクエストのために endio を忘れずに実行 (Sergey Senozhatsky) [Orabug: 39452420] {CVE-2026-46089}
    - ocfs2: 完了時にトランザクションを分割し、クレジットの枯渇を回避 (Heming Zhao) [Orabug: 39452388] {CVE-2026-46080}
    - drm/amdgpu: BO リストのエントリカウントを制限してリソースの枯渇を防ぐ (Jesse Zhang) [Orabug: 39167551] {CVE-2026-23468}
    - padata: pd UAF を完全に修正 (Herbert Xu) [Orabug: 38335055] {CVE-2025-38584}
    - drm/nouveau: pushbuf reloc 境界チェックの u32 オーバーフローを修正 (Greg Kroah-Hartman) [Orabug: 39452133] {CVE-2026-46006}
    - ALSA: usb-audio: MAX_NR_RATES で UAC2 レートの解析を停止 (Cassio Gabriel) [Orabug: 39452170] {CVE-2026-46018}
    - drivers/xen/sys-hypervisor.c のバッファオーバーフロー (Juergen Gross) [Orabug: 39305898] {CVE-2026-31786}
    - xen/privcmd: VMA 分割による二重解放を修正 (Juergen Gross) [Orabug: 39305908] {CVE-2026-31787}
    - rxrpc: 非 XDR キー準備で欠落しているチケット長の検証を修正 (Anderson Nascimento) [Orabug: 
    39300563] {CVE-2026-31696}
    - crypto: ccp: PSP コマンドが失敗した場合、ID をユーザー空間にコピーしようとしない (Sean Christopherson) {CVE-2026-31697}
    - crypto: ccp: PSP コマンドが失敗した場合、PDH cert をユーザー空間にコピーしようとしない (Sean Christopherson) {CVE-2026-31698}
    - crypto: ccp: PSP コマンドが失敗した場合、CSR をユーザー空間にコピーしようとしない (Sean Christopherson) {CVE-2026-31699}
    - net/packet: tpacket_snd() の mmap'd vnet_hdr の TOCTOU 競合を修正 (Bingquan Chen) {CVE-2026-31700}
    - ALSA: caiaq: create_card() の USB デバイスで参照を取得 (Berk Cem Goksel) [Orabug: 39300586] {CVE-2026-31701}
    - smb: client: smb2_ioctl_query_info QUERY_INFO パスの OOB 読み取りを修正 (Michael Bommarito) [Orabug: 
    39300607] {CVE-2026-31708}
    - smb: client: モードビットを読み取る前に完全な NFS モードの SID が必要 (Michael Bommarito) [Orabug: 39343707] {CVE-2026-43350}
    - fuse: ページキャッシュでオーバーサイズのディレントを拒否 (Samuel Page) [Orabug: 39300556] {CVE-2026-31694}
    - mm/pagewalk: 同時分割と再障害の間の競合を修正 (Max Boone) [Orabug: 39250782] {CVE-2026-31456}
    - wifi: mac80211: ieee80211_tx_prepare_skb() 失敗時に skb を常に解放 (Felix Fietkau) [Orabug: 39167472] {CVE-2026-23444}
    - mm/userfaultfd: hugetlb 障害 mutex ハッシュ計算を修正 (Jianhui Zhou) [Orabug: 39273453] {CVE-2026-31575}
    - ipv6: SRv6 パスの idev の NULL チェックを追加 (Heminhong) [Orabug: 39167467] {CVE-2026-23442}
    - ocfs2: ocfs2_write_end_inline での領域外書き込みを修正 (Joseph Qi) [Orabug: 39331090] {CVE-2026-43075}
    - ocfs2: inode の読み取り中にインラインデータの i_size を検証 (Deepanshu Kartikey) [Orabug: 39331097] {CVE-2026-43076}
    - media: as102: デバイスが as102_usb_probe() に登録された後、メモリを解放しないように修正 (Jeongjun Park) [Orabug: 39273467] {CVE-2026-31578}
    - bcache: cached_dev.sb_bio の use-after-free およびクラッシュを修正 (Mingzhe Zou) [Orabug: 39273481] {CVE-2026-31580}
    - ALSA: 6fire: 切断時の use-after-free を修正 (Berk Cem Goksel) [Orabug: 39273486] {CVE-2026-31581}
    - media: em28xx: em28xx_v4l2_open() の use-after-free を修正 (Abhishek Kumar) [Orabug: 39273493] {CVE-2026-31583}
    - mm: blk-cgroup: cgwb_release_workfn() の use-after-free を修正 (Breno Leitao) [Orabug: 39273507] {CVE-2026-31586}
    - KVM: x86: MMIO フラグメントのスクラッチフィールドを使用して、小さな書き込み値を保持 (Sean Christopherson) [Orabug: 
    39273521] {CVE-2026-31588}
    - x86-64: 誤解を招くような「__copy_user_nocache()」関数の名前を変更 (Linus Torvalds) [Orabug: 39323162] {CVE-2026-43073}
    - kernel: dup_mmap() の失敗と uprobe 登録について、より慎重になる (Liam R. Howlett) {CVE-2025-21709}
    - gpiolib: gdev->srcu の競合状態を修正 (Pawel Narewski) [Orabug: 38887677] {CVE-2026-22986}
    - KVM: SEV: KVM_MEMORY_ENCRYPT_REG_REGION 用の大きなサイズでの WARN のドロップ (Sean Christopherson) [Orabug: 
    39273529] {CVE-2026-31590}
    - KVM: SEV: すでに起動/暗号化された vCPU の VMSA を同期する試みを拒否 (Sean Christopherson) [Orabug: 39273553] {CVE-2026-31593}
    - ocfs2: ocfs2_group_extend の無効な dinode を処理 (Zhengyuan Huang) [Orabug: 39273569] {CVE-2026-31596}
    - ocfs2: VM_FAULT_RETRY 時の ocfs2_fault() の use-after-free を修正 (Tejas Bharambe) [Orabug: 39273578] {CVE-2026-31597}
    - ocfs2: nlink と dio_end_io_write の間の潜在的なデッドロックを修正 (Joseph Qi) [Orabug: 39273586] {CVE-2026-31598}
    - dcache: バケットの最小数を 2 つに制限 (Zhihao Cheng) [Orabug: 39323133] {CVE-2026-43071}
    - ALSA: ctxfi: PTP を単一ページに制限 (Harin Lee) [Orabug: 39273608] {CVE-2026-31602}
    - wifi: rtw88: プローブ障害でのデバイス漏洩を修正 (Johan Hovold) [Orabug: 39273620] {CVE-2026-31604}

Tenable は、前述の記述ブロックを Oracle Linux セキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
335080	openSUSE 16:cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21555-1)	Nessus	SuSE Local Security Checks	2026/8/13	2026/9/19	high
329149	SUSE SLED15 / SLES15: Linux カーネルのセキュリティ更新 (SUSE-SU-2026:3166-1)	Nessus	SuSE Local Security Checks	2026/7/23	2026/9/29	medium
313353	Linux Distros のパッチ未適用の脆弱性: CVE-2026-43436	Nessus	Misc.	2026/5/8	2026/11/6	medium
361263	Rocky Linux 9.6 [TuxCare] セキュリティ更新プログラム:kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1780562693)	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/21	high
340680	Ubuntu 24.04 LTS/Pro Realtime 24.04 LTS:Linuxカーネル(Raspberry Pi)の脆弱性(USN-8665-1)	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/8/27	high
361300	AlmaLinux 9.6 [TuxCare] セキュリティ更新プログラム:kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1780562693)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/21	high
360687	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2026:1783362244)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/19	high
325292	Oracle Linux 10 / 9 : Unbreakable Enterprise カーネル (ELSA-2026-50372)	Nessus	Oracle Linux Local Security Checks	2026/7/6	2026/10/29	high

検出

プラグインの検索

high

medium

medium

high

high

high

high

high