CentOS Linux 8 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個漏洞 （CENTOS-STREAM8：CLSA-2026：1792239979）
high Nessus Plugin ID 366781
語言:
概要
CentOS Linux 主機缺少一個或多個安全性更新。說明
CentOS Linux 8 主機已安裝的套件受到 TuxCare CENTOS-STREAM8：CLSA-2026：1792239979 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to
->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx.
This works accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40
__ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440
__extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.
(CVE-2021-46984)
- 儅使用者呼叫第一個 gru_file_unlocked_ioctl 函式時，在 Linux 核心的 SGI GRU 驅動程式中發現一個釋放後使用缺陷，其中 gru_check_chiplet_assignment 函式發生失敗。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-3424)
- 已解決 Linux 核心中的下列弱點：bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in
__skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
__lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
__arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line. (CVE-2022-49840)
- 已解決 Linux 核心中的下列弱點：usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to
->disconnect() by historic commit [PATCH] USB: usbnet, prevent exotic rtnl deadlock:
https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf (drivers/net: don't use flush_scheduled_work()). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last. (CVE-2022-50220)
- 已解決 Linux 核心中的下列弱點：cifs: fix oops during encryption When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25:
DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate:
80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr :
scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27:
0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18:
0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 :
ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 :
ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. (CVE-2022-50341)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 CENTOS-STREAM8：CLSA-2026：1792239979 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 366781
檔案名稱: tuxcare_centos_8_CLSA-2026-1792239979.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
風險因素: High
基本分數: 7.8
時間性分數: 5.8
媒介: CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:N
CVSS 評分資料來源: CVE-2023-39197
CVSS v3
風險因素: High
基本分數: 8.2
時間性分數: 7.1
媒介: CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
CVSS 評分資料來源: CVE-2026-31788
弱點資訊
必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2026/10/17
弱點發布日期: 2021/7/21
參考資訊
CVE: CVE-2021-46984, CVE-2022-3424, CVE-2022-49840, CVE-2022-50220, CVE-2022-50341, CVE-2022-50430, CVE-2023-39197, CVE-2023-52452, CVE-2023-53006, CVE-2023-53265, CVE-2023-53286, CVE-2023-53333, CVE-2023-53427, CVE-2023-53446, CVE-2023-53454, CVE-2023-53484, CVE-2023-54260, CVE-2024-56558, CVE-2025-38107, CVE-2025-38161, CVE-2025-38375, CVE-2025-38584, CVE-2025-38684, CVE-2025-39967, CVE-2025-39981, CVE-2025-40080, CVE-2025-68347, CVE-2025-68371, CVE-2026-22998, CVE-2026-31663, CVE-2026-31788, CVE-2026-43491, CVE-2026-46199, CVE-2026-46230, CVE-2026-63917, CVE-2026-63921, CVE-2026-64237, CVE-2026-64304, CVE-2026-64305, CVE-2026-64323, CVE-2026-64341, CVE-2026-64348, CVE-2026-64375, CVE-2026-64422, CVE-2026-64438, CVE-2026-64448, CVE-2026-68096, CVE-2026-68129, CVE-2026-68188, CVE-2026-68286, CVE-2026-68294, CVE-2026-68324, CVE-2026-68362, CVE-2026-68432, CVE-2026-72055, CVE-2026-72402, CVE-2026-72413, CVE-2026-72476, CVE-2026-74255, CVE-2026-74282, CVE-2026-74283, CVE-2026-74289, CVE-2026-74408, CVE-2026-74744, CVE-2026-80529, CVE-2026-80622, CVE-2026-97445, CVE-2026-98196, CVE-2026-98217, CVE-2026-98320, CVE-2026-98342, CVE-2026-98357, CVE-2026-99999
CLSA: 2026:1792239979