遠端 Ubuntu 16.04 ESM / 18.04 LTS 主機上安裝的一個套件受到 USN-6081-1 公告中提及的多個弱點影響。

  - Linux 核心 64 位元版本上的 Copy_from_user 未實作 __uaccess_begin_nospec，允許使用者繞過 access_ok 檢查並將核心指標傳遞至 copy_from_user()。這將允許攻擊者洩漏資訊。我們建議在 commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 之後的應用程式進行升級 (CVE-2023-0459)

  - 在整合 Linux 核心的紅外線接收器/收發器驅動程式中，發現使用者卸離 rc 裝置的方式存在釋放後使用瑕疵。本機使用者可利用此缺陷使系統當機，或可能提升其在系統中的權限。(CVE-2023-1118)

  - 在 KVM 中發現一個缺陷。在 32 位元系統上呼叫 KVM_GET_DEBUGREGS ioctl 時，kvm_debugregs 結構的某些未初始化部分可能會被復製到使用者空間，進而造成資訊洩漏。(CVE-2023-1513)

  - 在 Linux 核心的 SCSI 子元件中，發現 drivers/scsi/iscsi_tcp.c 的 iscsi_sw_tcp_session_create 存在釋放後使用弱點。攻擊者可利用此瑕疵洩漏核心內部資訊。
    (CVE-2023-2162)

  - 在 6.1.11 版之前的 Linux 核心中發現一個問題。net/netrom/af_netrom.c 中存在釋放後使用弱點，這是因為成功連線的 AF_NETROM 通訊端也允許接受。不過，攻擊者利用此弱點的前提是，系統必須已設定 netrom 路由，或攻擊者必須具備 CAP_NET_ADMIN 功能。(CVE-2023-32269)

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

遠端 Ubuntu 18.04 LTS/20.04 LTS 主機上安裝的一個套件受到 USN-6118-1 公告中所提及的多個弱點影響。

  - 在 Linux 核心中發現重複釋放記憶體缺陷。Intel GVT-g 圖形驅動程式觸發 VGA 卡系統資源過載，造成 intel_gvt_dma_map_guest_page 函式失敗。本機使用者可利用此問題導致系統當機。(CVE-2022-3707)

  - Linux 核心 64 位元版本上的 Copy_from_user 未實作 __uaccess_begin_nospec，允許使用者繞過 access_ok 檢查並將核心指標傳遞至 copy_from_user()。這將允許攻擊者洩漏資訊。我們建議在 commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 之後的應用程式進行升級 (CVE-2023-0459)

  - 在 Linux 核心中發現一個缺陷。tls_is_tx_ready() 未正確檢查清單是否空白，可能存取 list_head 的類型混淆項目，進而洩漏與 rec->tx_ready 重疊的混淆欄位的最後一個位元組。(CVE-2023-1075)

  - 在 Linux 核心的可靠資料包通訊端 (RDS) 通訊協定實作中發現一個瑕疵。rds_rm_zerocopy_callback() 在清單標頭上使用 list_entry()，可造成類型混淆。本機使用者可透過 rds_message_put() 觸發此問題。類型混淆導致 `struct rds_zcopy_info *info` 實際上指向可能由本機使用者控制的其他內容。目前已知此問題的觸發方式，觸發後可造成超出邊界存取和鎖定損毀。(CVE-2023-1078)

  - 在整合 Linux 核心的紅外線接收器/收發器驅動程式中，發現使用者卸離 rc 裝置的方式存在釋放後使用瑕疵。本機使用者可利用此缺陷使系統當機，或可能提升其在系統中的權限。(CVE-2023-1118)

  - 在 KVM 中發現一個缺陷。在 32 位元系統上呼叫 KVM_GET_DEBUGREGS ioctl 時，kvm_debugregs 結構的某些未初始化部分可能會被復製到使用者空間，進而造成資訊洩漏。(CVE-2023-1513)

  - 在 Linux 核心的 SCSI 子元件中，發現 drivers/scsi/iscsi_tcp.c 的 iscsi_sw_tcp_session_create 存在釋放後使用弱點。攻擊者可利用此瑕疵洩漏核心內部資訊。
    (CVE-2023-2162)

  - 在 6.1.11 版之前的 Linux 核心中發現一個問題。net/netrom/af_netrom.c 中存在釋放後使用弱點，這是因為成功連線的 AF_NETROM 通訊端也允許接受。不過，攻擊者利用此弱點的前提是，系統必須已設定 netrom 路由，或攻擊者必須具備 CAP_NET_ADMIN 功能。(CVE-2023-32269)

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

CentOS Linux 8.5 主機已安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1792247642 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：ethtool: do not perform operations on net devices being unregistered There is a short period between a net device starts to be unregistered and when it is actually gone. In that time frame ethtool operations could still be performed, which might end up in unwanted or undefined behaviours[1]. Do not allow ethtool operations after a net device starts its unregistration. This patch targets the netlink part as the ioctl one isn't affected: the reference to the net device is taken and the operation is executed within an rtnl lock section and the net device won't be found after unregister. [1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace:
    dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610 (CVE-2021-47517)

  - 已解決 Linux 核心中的下列弱點：nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.
    (CVE-2022-48686)

  - 已解決 Linux 核心中的下列弱點：net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator.
    NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection) ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148]
    __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 (CVE-2022-49667)

  - 已解決 Linux 核心中的下列弱點：bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32
    *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18:
    w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. (CVE-2022-49961)

  - 在 Linux 核心的 SCSI 子元件中，發現 drivers/scsi/iscsi_tcp.c 的 iscsi_sw_tcp_session_create 存在釋放後使用弱點。攻擊者可利用此瑕疵洩漏核心內部資訊。
    (CVE-2023-2162)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
175884	Ubuntu 16.04 ESM/18.04 LTS：Linux 核心弱點 (USN-6081-1)	Nessus	Ubuntu Local Security Checks	2023/5/16	2024/8/27	high
176493	Ubuntu 18.04 LTS / 20.04 LTS : Linux 核心 (Oracle) 弱點 (USN-6118-1)	Nessus	Ubuntu Local Security Checks	2023/5/30	2024/8/28	high
366854	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2026：1792247642）	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/17	high

偵測

搜尋 Plugin

high

high

high