CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點 （CENTOS8.5：CLSA-2026：1792979985）
high Nessus Plugin ID 371988
語言:
概要
CentOS Linux 主機缺少一個或多個安全性更新。說明
CentOS Linux 8.5 主機已安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1792979985 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：net: bridge: fix vlan tunnel dst refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm:
ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP:
0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08:
0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge]
__br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
__netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2
__netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow (CVE-2021-47222)
- 已解決 Linux 核心中的下列弱點：net: bridge: fix vlan tunnel dst null pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking.
Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked in the egress path. (CVE-2021-47223)
- 已解決 Linux 核心中的下列弱點：bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset.
The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904 (CVE-2023-52676)
- 已解決 Linux 核心中的下列弱點：cifs: fix session state check in reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)
- 已解決 Linux 核心中的下列弱點：ubi: Fix use-after-free when volume resizing failed There is an use-after-free problem reported by KASAN:
================================================================== BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2 PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi] ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record() returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume resizing. (CVE-2023-53800)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 CENTOS8.5：CLSA-2026：1792979985 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 371988
檔案名稱: tuxcare_centos_8.5_CLSA-2026-1792979985.nasl
版本: 1.1
類型: Local
代理程式: unix
已發布: 2026/10/26
已更新: 2026/10/26
支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: High
分數: 7.7
百分位數: 98.94
Vendor
Vendor Severity: Critical
CVSS v2
風險因素: Medium
基本分數: 6.8
時間性分數: 5
媒介: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2026-64424
CVSS v3
風險因素: High
基本分數: 7.8
時間性分數: 6.8
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
弱點資訊
必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2026/10/26
弱點發布日期: 2021/7/16
參考資訊
CVE: CVE-2021-47222, CVE-2021-47223, CVE-2022-50880, CVE-2023-52676, CVE-2023-53794, CVE-2023-53800, CVE-2024-49948, CVE-2025-37882, CVE-2025-68283, CVE-2025-68822, CVE-2026-100072, CVE-2026-22998, CVE-2026-43279, CVE-2026-45920, CVE-2026-45970, CVE-2026-45984, CVE-2026-46047, CVE-2026-46052, CVE-2026-46069, CVE-2026-46116, CVE-2026-46135, CVE-2026-46150, CVE-2026-46180, CVE-2026-46191, CVE-2026-46227, CVE-2026-46259, CVE-2026-46266, CVE-2026-46319, CVE-2026-52917, CVE-2026-52923, CVE-2026-52929, CVE-2026-52935, CVE-2026-52942, CVE-2026-52947, CVE-2026-52955, CVE-2026-52991, CVE-2026-53002, CVE-2026-53053, CVE-2026-53078, CVE-2026-53089, CVE-2026-53120, CVE-2026-53131, CVE-2026-53189, CVE-2026-53224, CVE-2026-53239, CVE-2026-53246, CVE-2026-53254, CVE-2026-53255, CVE-2026-53374, CVE-2026-53388, CVE-2026-53392, CVE-2026-53397, CVE-2026-53399, CVE-2026-63887, CVE-2026-63888, CVE-2026-63892, CVE-2026-63916, CVE-2026-63962, CVE-2026-63983, CVE-2026-63992, CVE-2026-64007, CVE-2026-64015, CVE-2026-64114, CVE-2026-64191, CVE-2026-64363, CVE-2026-64378, CVE-2026-64381, CVE-2026-64424, CVE-2026-64543, CVE-2026-68377, CVE-2026-72262, CVE-2026-72322, CVE-2026-72323, CVE-2026-72398, CVE-2026-72413, CVE-2026-74268, CVE-2026-74283, CVE-2026-74289, CVE-2026-74345, CVE-2026-74359, CVE-2026-74386, CVE-2026-74387, CVE-2026-74388, CVE-2026-74390, CVE-2026-74450, CVE-2026-74479, CVE-2026-74481, CVE-2026-74505, CVE-2026-74510, CVE-2026-74550, CVE-2026-74569, CVE-2026-74656, CVE-2026-80590, CVE-2026-80622, CVE-2026-80676, CVE-2026-80841, CVE-2026-80971, CVE-2026-80994, CVE-2026-89448, CVE-2026-89477, CVE-2026-89480, CVE-2026-89481, CVE-2026-89482, CVE-2026-89488, CVE-2026-89530, CVE-2026-89549, CVE-2026-89559, CVE-2026-89633, CVE-2026-89637, CVE-2026-89671, CVE-2026-89685, CVE-2026-89786, CVE-2026-89892, CVE-2026-89965, CVE-2026-89972, CVE-2026-90000, CVE-2026-90011, CVE-2026-90013, CVE-2026-90067, CVE-2026-90116, CVE-2026-90383, CVE-2026-90421, CVE-2026-93099, CVE-2026-93117, CVE-2026-93163, CVE-2026-93228, CVE-2026-93251, CVE-2026-93791, CVE-2026-97445, CVE-2026-97455, CVE-2026-97509, CVE-2026-97540, CVE-2026-97541, CVE-2026-97564, CVE-2026-97931, CVE-2026-97938, CVE-2026-97991, CVE-2026-98015, CVE-2026-98019, CVE-2026-98025, CVE-2026-98041, CVE-2026-98077, CVE-2026-98108, CVE-2026-98175, CVE-2026-98185, CVE-2026-98276, CVE-2026-98312, CVE-2026-98342, CVE-2026-98357, CVE-2026-98367, CVE-2026-98588, CVE-2026-98606, CVE-2026-98687, CVE-2026-98739
CLSA: 2026:1792979985