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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 Oracle Linux 10 / 9 主機中安裝的套件受到 ELSA-2026-50372 公告中提及的多個弱點影響。

    - net/sched：修正導致頁面快取損毀的 pedit 部分 COW (Rajat Gupta) {CVE-2026-46331}
    - eventpoll：修正ep_remove結構 eventpoll / 結構檔案 UAF （Christian Brauner） [Orabug： 39668743] {CVE-2026-46242}
    - net： skbuff：修正 pskb_carve 協助程式中缺少的 zerocopy 參照 （Minh Nguyen） [Orabug： 39656679] {CVE-2026-52943}
    - arm64： 勘誤表：緩解各種 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：透過片段傳輸協助程式傳播共用片段標記 (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 參照計數洩漏 （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() 中的釋放後使用 (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（） 中的釋放後使用 （Daniel Hodges） [Orabug： 39452343] {CVE-2026-46069}
    - thermal： core：修正熱區域調速器清理問題 （Rafael J. Wysocki） [Orabug： 39452186] {CVE-2026-46021}
    - smb：client：在 cifsacl 中重寫 DACL 之前先驗證整個 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() 中使用 waiter::task 而不是 current (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}
    - 藍牙：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 的 multishot recv （Jens Axboe） {CVE-2026-23473}
    - KVM： nSVM： 如果未處理的 VMMCALL 未被 L1 攔截，則引發 #UD （Kevin Cheng） [Orabug： 39452372] {CVE-2026-46076}
    - KVM： SVM：如果是 EFER，則為 INVLPGA 注入 #UD。SVME=0 （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：修正 device_add_disk（） 失敗時的 null-ptr-deref （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：修正尾隨 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（） 中的釋放後使用 （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 上游橋接器是否存在 （Fedor Pchelkin） [Orabug： 39452437] {CVE-2026-46092}
    - zram：不要忘記部分捨棄請求的 endio （Sergey Senozhatsky） [Orabug： 39452420] {CVE-2026-46089}
    - ocfs2：在 dio 完成時拆分交易以避免信用耗盡 （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 重新定位邊界檢查中的 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：修正並行分割和重新fault之間的爭用 （Max Boone） [Orabug： 39250782] {CVE-2026-31456}
    - wifi： mac80211：ieee80211_tx_prepare_skb（） 失敗時始終釋放 skb （Felix Fietkau） [Orabug： 39167472] {CVE-2026-23444}
    - mm/userfaultfd：修正 hugetlb 錯誤互斥雜湊計算 （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 釋放後使用和崩潰 （Mingzhe Zou） [Orabug： 39273481] {CVE-2026-31580}
    - ALSA： 6fire：修正中斷連接時的釋放後使用 （Berk Cem Goksel） [Orabug： 39273486] {CVE-2026-31581}
    - media： em28xx：修正 em28xx_v4l2_open（） 中的釋放後使用 （Abhishek Kumar） [Orabug： 39273493] {CVE-2026-31583}
    - mm： blk-cgroup：修正 cgwb_release_workfn（） 中的釋放後使用 （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：修正 ocfs2_fault（） 中VM_FAULT_RETRY時的釋放後使用 （Tejas Bharambe） [Orabug： 39273578] {CVE-2026-31597}
    - ocfs2：修正取消連結和dio_end_io_write之間可能的鎖死 （Joseph Qi） [Orabug： 39273586] {CVE-2026-31598}
    - dcache：將儲存桶的最小數量限制為兩個 （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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - nvme-pci：修正 nvme_poll_irqdisable（） 中的爭用錯誤 在以下場景中，可以透過 （2） 在 （1） 和 （3） 之間停用 pdev。這會設定 pdev->msix_enabled = 0。然後，pci_irq_vector（） 將針對 （1） 傳回 MSI-X IRQ（>15），而針對 （2） 傳回 INTx IRQ（<=15）。這會導致 IRQ 警告，因為它會嘗試啟用以前從未停用過的 INTx IRQ。若要解決此問題，請將 IRQ 編號儲存到本機變數中，並確保 disable_irq（） 和 enable_irq（） 在相同的 IRQ 編號上運作。即使 pci_free_irq_vectors（） 同時釋放 IRQ，過時 IRQ 編號上的 disable_irq（） 和 enable_irq（） 仍然有效且安全，並且深度帳戶會保持平衡。作業 1：nvme_poll_irqdisable（） disable_irq（pci_irq_vector（pdev， nvmeq->cq_vector）） ...（1） enable_irq（pci_irq_vector（pdev， nvmeq->cq_vector）） ...（3）任務2：
    nvme_reset_work（） nvme_dev_disable（） pdev->msix_enable = 0;...（2） 崩潰日誌：------------[ 切到此處]------------ IRQ 10 的不平衡啟用 警告：kernel/irq/manage.c：753 at __enable_irq+0x102/0x190 kernel/irq/manage.c：753， CPU#1： kworker/1：0H/26 連結的模組： CPU： 1 UID： 0 PID： 26 通訊：
    kworker/1：0H 未受污染 6.19.0-dirty #9 PREEMPT（自願） 硬體名稱：QEMU 標準 PC （i440FX + PIIX， 1996），BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 2014/04/01 工作佇列：kblockd blk_mq_timeout_work RIP：0010：__enable_irq+0x107/0x190 kernel/irq/manage.c：753 程式碼：ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP： 0018：ffffc900001bf550 EFLAGS：
    00010046 RAX：0000000000000007 RBX：000000000000000000 RCX：ffffffffb20c0e90 RDX：000000000000000000000000 RSI：
    000000000000000a RDI：ffffffffb74b88f0 RBP：ffffc900001bf560：ffff88800197cf00R09：0000000000000001：0000000000000003R10R11：0000000000000003R12：ffff8880012a6000：R131ffff92000037eaeR14：R08
    000000000000000a R15：0000000000000293 FS：00000000000000000（0000） GS：ffff8880b49f7000（0000） knlGS：000000000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：0000555da4a25fa8 CR3：
    00000000208e8000 CR4： 00000000000006f0 呼叫追蹤： <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c：797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c：1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c：1744 blk_mq_rq_timed_out block/blk-mq.c：1653 [內嵌] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c：1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c：292
    __sbitmap_for_each_set include/linux/sbitmap.h：269 [內聯] sbitmap_for_each_set include/linux/sbitmap.h：290 [內聯] bt_for_each block/blk-mq-tag.c：324 [內聯] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c：536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c：1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c：3257 process_scheduled_works kernel/workqueue.c：3340 [內聯] worker_thread+0x65c/0xe60 kernel/workqueue.c：3421 kthread+0x41a/0x930 kernel/kthread.c：463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：246 </TASK> irq 事件戳記：74478 hardirq 上次啟用時間為 （74477）：
    [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h：159 [inline] hardirqs 上次啟用時間為 （74477）： [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c：202 hardirqs 上次停用時間為 （74478）： [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h：108 [inline] hardirqs 上次停用時間為 （74478）： [<ffffffffb57207b5>]
    _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c：162 softirqs 上次啟用時間為 （74304）：
    [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c：656 [inline] softirqs 上次啟用時間為 （74304）：
    [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c：496 [inline] softirqs 上次啟用時間為 （74304）：
    [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120 ---truncated--- （CVE-2026-43448）

請注意，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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

因此，會受到 ALAS2023-2026-1594 公告中所提及的多個弱點影響。

    在 Linux 核心中，下列弱點已解決：

    netfilter： ctnetlink：移除預期轉儲程式中的參照計數 （CVE-2025-39764）

    在 Linux 核心中，下列弱點已解決：

    ipv6：在 ip6_xmit（） 中使用 RCU （CVE-2025-40135）

    在 Linux 核心中，下列弱點已解決：

    blk-throttle：修正節流策略啟動期間的存取爭用 （CVE-2025-40147）

    在 Linux 核心中，下列弱點已解決：

    binfmt_misc：在關閉 open_exec（）CVE-2025-68239 （） 開啟的檔案之前還原寫入存取權

    在 Linux 核心中，下列弱點已解決：

    dm-verity：停用遞迴前向糾錯 （CVE-2025-71161）

    在 Linux 核心中，下列弱點已解決：

    dst：修正 rt6_uncached_list_del（） 和 rt_del_uncached_list（） 中的爭用 （CVE-2026-23004）

    在 Linux 核心中，下列弱點已解決：

    跟蹤：在核心堆疊追蹤記錄中新增遞迴保護 （CVE-2026-23138）

    在 Linux 核心中，下列弱點已解決：

    netfilter： xt_IDLETIMER：拒絕 rev0 重複使用 ALARM 計時器標籤 （CVE-2026-23274）

    在 Linux 核心中，下列弱點已解決：

    net：將 XMIT 遞迴限制新增至通道 XMIT 函式 （CVE-2026-23276）

    在 Linux 核心中，下列弱點已解決：

    net/sched： teql：修正 TEQL 從屬 xmit （CVE-2026-23277） 上 iptunnel_xmit 中的 NULL 指標解除參照

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_tables：始終遍歷所有擱置的 catchall 元素 （CVE-2026-23278）

    在 Linux 核心中，下列弱點已解決：

    mptcp： pm： in-kernel：一律將 signal+subflow endp 標記為已使用 （CVE-2026-23321）

    在 Linux 核心中，下列弱點已解決：

    net： phy：在探測期間註冊 phy led_triggers以避免 AB-BA 鎖死 （CVE-2026-23368）

    在 Linux 核心中，下列弱點已解決：

    mm：thp：拒絕匿名 inode 上檔案的 THP （CVE-2026-23375）

    在 Linux 核心中，下列弱點已解決：

    netfilter： xt_CT：在模板移除時丟棄擱置的排入佇列封包 （CVE-2026-23391）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_tables：在錯誤 （CVE-2026-23392） 的 RCU 寬限期後釋放流程表

    在 Linux 核心中，下列弱點已解決：

    nfnetlink_osf：驗證指紋中的個別選項長度 （CVE-2026-23397）

    在 Linux 核心中，下列弱點已解決：

    icmp：修正 icmp_tag_validation（） 中的 NULL 指標解除參照 （CVE-2026-23398）

    在 Linux 核心中，下列弱點已解決：

    nf_tables： nft_dynset：修正錯誤路徑 （CVE-2026-23399） 中可能的有狀態運算式 memleak

    在 Linux 核心中，下列弱點已解決：

    netfilter： bpf：延遲鉤子記憶體釋放，直到 RCU 讀取器完成 （CVE-2026-23412）

    在 Linux 核心中，下列弱點已解決：

    clsact：修正 init/destroy 復原不對稱中的釋放後使用 （CVE-2026-23413）

    在 Linux 核心中，下列弱點已解決：

    udp_tunnel：修正 CONFIG_IPV6=n （） 時由 udp_sock_create6 引起的 NULL 解除參照 （CVE-2026-23439）

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e：修正 IPSec ESN 更新期間的爭用情形 （CVE-2026-23440）

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e：防止並行存取 IPSec ASO 上下文 （CVE-2026-23441）

    在 Linux 核心中，下列弱點已解決：

    ACPI： 處理器：修正先前的 acpi_processor_errata_piix4（） 修正 （CVE-2026-23443）

    在 Linux 核心中，下列弱點已解決：

    igc：修正 XDP TX 時間戳記處理中的頁面錯誤 （CVE-2026-23445）

    在 Linux 核心中，下列弱點已解決：

    net/sched： teql：修正 teql_master_xmit 中的雙重釋放 （CVE-2026-23449）

    在 Linux 核心中，下列弱點已解決：

    PM： runtime：修正與裝置移除相關的爭用情形 （CVE-2026-23452）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_conntrack_h323：檢查 DecodeQ931（） 中的零長度 （CVE-2026-23455）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_conntrack_h323：修正 decode_int（） 中的 OOB 讀取 缺點 （CVE-2026-23456）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_conntrack_sip：修正 sip_help_tcp（）CVE-2026-23457 （） 中的內容長度 u32 截斷

    在 Linux 核心中，下列弱點已解決：

    netfilter： ctnetlink：修正 ctnetlink_dump_exp_ct（） 中的釋放後使用 （CVE-2026-23458）

    在 Linux 核心中，下列弱點已解決：

    btrfs：記錄衝突 inode 的父目錄時，記錄新的 dentry （CVE-2026-23465）

    在 Linux 核心中，下列弱點已解決：

    spi：修正統計資料分配 （CVE-2026-23475）

    在 Linux 核心中，下列弱點已解決：

    SPI：修正控制器註冊失敗時的釋放後使用 （CVE-2026-31389）

    在 Linux 核心中，下列弱點已解決：

    SMB： client：使用使用者名稱選項 （）CVE-2026-31392 修正 krb5 掛載

    在 Linux 核心中，下列弱點已解決：

    nvdimm/bus：修正非同步初始化中釋放後的潛在使用 （CVE-2026-31399）

    在 Linux 核心中，下列弱點已解決：

    sunrpc：修正 cache_release （CVE-2026-31400） 中的cache_request洩露

    在 Linux 核心中，下列弱點已解決：

    HID： bpf：防止 hid_hw_request 中的緩衝區溢位 （CVE-2026-31401）

    在 Linux 核心中，下列弱點已解決：

    nfsd：修正 NFSv4.0 LOCK 重播快取中的堆積溢位 （CVE-2026-31402）

    在 Linux 核心中，下列弱點已解決：

    NFSD：在 /proc/fs/nfs/exports fd （CVE-2026-31403） 的存留期內保留淨參照

    在 Linux 核心中，下列弱點已解決：

    drm/i915/gt：在延遲 （CVE-2026-31540） 之前檢查 set_default_submission（）

    在 Linux 核心中，下列弱點已解決：

    net： bonding：修正 bond_debug_rlb_hash_show （CVE-2026-31546） 中的 NULL 解除參照

    在 Linux 核心中，下列弱點已解決：

    xen/privcmd：限制在無權限的 domU 中使用 （CVE-2026-31788）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nft_ct：移除時丟棄擱置的排入佇列封包 （CVE-2026-43060）

    在 Linux 核心中，下列弱點已解決：

    serial： 8250： 修正使用 DMA 時的 TX 鎖死 （CVE-2026-43061）

    在 Linux 核心中，下列弱點已解決：

    mptcp： pm： in-kernel：當 rm endp （CVE-2026-43252） 時，一律將 ID 設定為 avail

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正由於項目溢位而導致的集合收到 ioctl 上的事務中止 （CVE-2026-43359）

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正檔案建立時由於名稱雜湊衝突而導致的事務中止 （CVE-2026-43360）

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正對收到的子磁碟區進行快照時的事務中止 （CVE-2026-43361）

    在 Linux 核心中，下列弱點已解決：

    SMB： 用戶端：修正 SMB2_write（）CVE-2026-43362 （） 中的就地加密損毀

    在 Linux 核心中，下列弱點已解決：

    x86/apic： 如果核心預期，則在繼續時停用 x2apic （CVE-2026-43363）

    在 Linux 核心中，下列弱點已解決：

    xfs：修正過小的l_iclog_roundoff值 （CVE-2026-43365）

    在 Linux 核心中，下列弱點已解決：

    io_uring/kbuf：檢查目標緩衝區清單在回收時是否仍為舊版 （CVE-2026-43366）

    在 Linux 核心中，下列弱點已解決：

    drm/i915：修正 shmem 散佈清單長度的潛在溢位 （CVE-2026-43368）

    在 Linux 核心中，下列弱點已解決：

    net： nexthop：修正 remove_nh_grp_entry （CVE-2026-43374） 中的 percpu 釋放後使用

    在 Linux 核心中，下列弱點已解決：

    net/tcp-md5：將 MAC 比較修正為恆定時間 （CVE-2026-43383）

    在 Linux 核心中，下列弱點已解決：

    net/tcp-ao：將 MAC 比較修正為恆定時間 （CVE-2026-43384）

    在 Linux 核心中，下列弱點已解決：

    sched_ext：修正一般類別飽和度下 scx_enable（） 的匱乏 （CVE-2026-43392）

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正 btrfs_chunk_map_num_copies（） 之後 btrfs_map_block（） 中的區塊映射洩漏 （CVE-2026-43393）

    在 Linux 核心中，下列弱點已解決：

    nfsd：修正 nfsd_nl_listener_set_doit（） 中的 cred ref 洩漏。（CVE-2026-43394）

    在 Linux 核心中，下列弱點已解決：

    nsfs：加強對 ns 反覆專案 ioctl 的權限檢查 （CVE-2026-43403）

    在 Linux 核心中，下列弱點已解決：

    libceph：針對 ceph_monmap_decode（）CVE-2026-43405 （） 中的非負值使用 u32

    在 Linux 核心中，下列弱點已解決：

    libceph：防止 process_message_header（） 中潛在的越界讀取 （CVE-2026-43406）

    在 Linux 核心中，下列弱點已解決：

    libceph：修正 ceph_handle_auth_reply（） 中潛在的越界存取 （CVE-2026-43407）

    在 Linux 核心中，下列弱點已解決：

    ceph：新增一堆遺漏的 ceph_path_info 初始化程式 （CVE-2026-43408）

    在 Linux 核心中，下列弱點已解決：

    kprobes：避免 ftrace 終止後 rmmod/insmod 當機 （CVE-2026-43409）

    在 Linux 核心中，下列弱點已解決：

    tipc：修正 tipc_sk_filter_connect（） 中的除以零 （CVE-2026-43411）

    在 Linux 核心中，下列弱點已解決：

    ceph：修正 ceph_mdsc_build_path（） 中的記憶體洩漏 （CVE-2026-43419）

    在 Linux 核心中，下列弱點已解決：

    Ceph：修正非同步解除連結期間的 i_nlink 不足 （CVE-2026-43420）

    在 Linux 核心中，下列弱點已解決：

    USB： 類別：cdc-wdm：修正讀取程式碼路徑 （CVE-2026-43427） 中的重新排序問題

    在 Linux 核心中，下列弱點已解決：

    USB： core：限制不可終止的同步逾時長度 （CVE-2026-43428）

    在 Linux 核心中，下列弱點已解決：

    usb： xhci：修正 xhci_disable_slot（） 中的記憶體洩漏 （CVE-2026-43432）

    在 Linux 核心中，下列弱點已解決：

    sched_ext：移除 scx_cgroup_init（）CVE-2026-43438 中多餘的 css_put（） （）

    在 Linux 核心中，下列弱點已解決：

    cgroup：修正任務遷移和迭代之間的爭用 （CVE-2026-43439）

    在 Linux 核心中，下列弱點已解決：

    net： bonding：修正停用 IPv6 時nd_tbl NULL 解除參照 （CVE-2026-43441）

    在 Linux 核心中，下列弱點已解決：

    e1000/e1000e：修正 DMA 錯誤清除中的洩漏 （CVE-2026-43445）

    在 Linux 核心中，下列弱點已解決：

    nvme-pci：修正 nvme_poll_irqdisable（） 中的爭用錯誤 （CVE-2026-43448）

    在 Linux 核心中，下列弱點已解決：

    nvme-pci：修正 nvme_dbbuf_set 中的 slab-out-of-bounds （CVE-2026-43449）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nfnetlink_cthelper：修正 nfnl_cthelper_dump_table（） 中的 OOB 讀取 （CVE-2026-43450）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nfnetlink_queue：修正橋接器判定錯誤路徑中的項目洩漏 （CVE-2026-43451）

    在 Linux 核心中，下列弱點已解決：

    netfilter： x_tables：保護選項步行程式免受 1 位元組尾部讀取 （CVE-2026-43452）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nft_set_pipapo：修正 pipapo_drop（） 中的堆疊越界讀取 （CVE-2026-43453）

    在 Linux 核心中，下列弱點已解決：

    bonding：修正 bond_setup_by_slave（） 中的類型混淆 （CVE-2026-43456）

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e：修正錯誤 CQE SQ 復原時的 DMA FIFO 不同步 （CVE-2026-43466）

    在 Linux 核心中，下列弱點已解決：

    net/mlx5：修正移至 switchdev 模式時的當機 （CVE-2026-43467）

    在 Linux 核心中，下列弱點已解決：

    net/mlx5： 修正 devlink 鎖定和 esw->wq （CVE-2026-43468） 之間的鎖死

    在 Linux 核心中，下列弱點已解決：

    nfs：如果 d_alias 是 dir （），則在 nfs3_proc_create 上傳回 EISDIR （CVE-2026-43470）

    在 Linux 核心中，下列弱點已解決：

    unshare：修正 unshare_fs（） 處理 （CVE-2026-43472）

    在 Linux 核心中，下列弱點已解決：

    scsi：mpi3mr：重設要求和回覆佇列時新增 NULL 檢查 （CVE-2026-43473）

    在 Linux 核心中，下列弱點已解決：

    scsi：storvsc：在 PREEMPT_RT 上修正不可部分完成時的排程 （CVE-2026-43475）

    在 Linux 核心中，下列弱點已解決：

    sched_ext：停用 scx_claim_exit（） 和踢出協助程式工作 （CVE-2026-43482） 之間的搶佔

    在 Linux 核心中，下列弱點已解決：

    KVM： SVM：當 AVIC 被 （取消） 啟動時，設定/清除 CR8 寫入攔截 （CVE-2026-43483）

    在 Linux 核心中，下列弱點已解決：

    arm64： contpte：修正 SMMU/ATS 故障的 set_access_flags（） 無操作檢查 （CVE-2026-43486）

    在 Linux 核心中，下列弱點已解決：

    ata： libata-core： 停用 ST1000DM010-2EP102 上的 LPM （CVE-2026-43487）

    在 Linux 核心中，下列弱點已解決：

    USB： xhci：防止主機控制器錯誤 （HCE） 上的中斷風暴 （CVE-2026-43488）

    在 Linux 核心中，下列弱點已解決：

    erofs：修正 ztailpacking pclusters 的內嵌資料讀取失敗 （CVE-2026-45943）

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
313522	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2026-1681)	Nessus	Amazon Linux Local Security Checks	2026/5/9	2026/9/1	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
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
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
325292	Oracle Linux 10 / 9：Unbreakable Enterprise 核心 (ELSA-2026-50372)	Nessus	Oracle Linux Local Security Checks	2026/7/6	2026/10/29	high
311340	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-1596)	Nessus	Amazon Linux Local Security Checks	2026/4/30	2026/6/17	high
313348	Linux Distros 未修補弱點：CVE-2026-43448	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
311335	Amazon Linux 2023：bpftool6.12、kernel6.12、kernel6.12-devel （ALAS2023-2026-1594）	Nessus	Amazon Linux Local Security Checks	2026/4/30	2026/6/17	high

偵測

搜尋 Plugin

high

high

high

high

high

high

medium

high

high