CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞 （CENTOS8.5：CLSA-2026：1792247642）
high Nessus 插件 ID 366854
语言：
简介
CentOS Linux 主机缺少一个或多个安全更新。描述
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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 CENTOS8.5：CLSA-2026：1792247642 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 366854
文件名: tuxcare_centos_8.5_CLSA-2026-1792247642.nasl
版本: 1.1
类型: Local
代理: unix
发布时间: 2026/10/17
最近更新时间: 2026/10/17
支持的传感器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: High
分数: 8
百分位: 99.69
Vendor
Vendor Severity: Important
CVSS v2
风险因素: Medium
基本分数: 6.8
时间分数: 5.3
矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 分数来源: CVE-2026-53136
CVSS v3
风险因素: High
基本分数: 7.8
时间分数: 7
矢量: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
时间矢量: CVSS:3.0/E:P/RL:O/RC:C
漏洞信息
必需的 KB 项: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可利用: true
易利用性: Exploits are available
补丁发布日期: 2026/10/17
漏洞发布日期: 2021/7/21
参考资料信息
CVE: CVE-2021-47517, CVE-2022-48686, CVE-2022-49667, CVE-2022-49961, CVE-2023-2162, CVE-2023-52515, CVE-2023-52974, CVE-2024-38556, CVE-2024-56558, CVE-2026-31500, CVE-2026-31581, CVE-2026-31669, CVE-2026-43304, CVE-2026-43493, CVE-2026-46006, CVE-2026-46209, CVE-2026-46294, CVE-2026-52993, CVE-2026-52998, CVE-2026-53064, CVE-2026-53136, CVE-2026-53138, CVE-2026-63801, CVE-2026-63829, CVE-2026-64109, CVE-2026-64115, CVE-2026-64546, CVE-2026-64548, CVE-2026-68142, CVE-2026-68202, CVE-2026-68365, CVE-2026-68398, CVE-2026-68414, CVE-2026-74589, CVE-2026-74609, CVE-2026-74641, CVE-2026-74667, CVE-2026-74669, CVE-2026-74700, CVE-2026-74746, CVE-2026-90103, CVE-2026-90203, CVE-2026-90334, CVE-2026-90382, CVE-2026-93054, CVE-2026-93262, CVE-2026-97536, CVE-2026-98354, CVE-2026-98375, CVE-2026-99999
CLSA: 2026:1792247642