CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞 （CENTOS7：CLSA-2026：1792976962）
high Nessus 插件 ID 374124
语言：
简介
CentOS Linux 主机缺少一个或多个安全更新。描述
CentOS Linux 7 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS7：CLSA-2026：2026：1792976962公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at if (pkt_len > 2 * MAX_RX_BUF_SIZE) { line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol. (CVE-2022-50709)
- 已修复 Linux 内核中的下列漏洞：configfs: fix possible memory leak in configfs_create_dir() kmemleak reported memory leaks in configfs_create_dir(): unreferenced object 0xffff888009f6af00 (size 192): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ...
*dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct. (CVE-2022-50751)
- 已修复 Linux 内核中的下列漏洞：pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP An oops can be induced by running 'cat /proc/kcore > /dev/null' on devices using pstore with the ram backend because kmap_atomic() assumes lowmem pages are accessible with __va(). Unable to handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU:
7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp :
ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21:
ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12:
0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 :
ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace:
__memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4 During early boot, memblock reserves the pages for the ramoops reserved memory node in DT that would otherwise be part of the direct lowmem mapping. Pstore's ram backend reuses those reserved pages to change the memory type (writeback or non-cached) by passing the pages to vmap() (see pfn_to_page() usage in persistent_ram_vmap() for more details) with specific flags. When read_kcore() starts iterating over the vmalloc region, it runs over the virtual address that vmap() returned for ramoops. In aligned_vread() the virtual address is passed to vmalloc_to_page() which returns the page struct for the reserved lowmem area. That lowmem page is passed to kmap_atomic(), which effectively calls page_to_virt() that assumes a lowmem page struct must be directly accessible with __va() and friends. These pages are mapped via vmap() though, and the lowmem mapping was never made, so accessing them via the lowmem virtual address oopses like above. Let's side-step this problem by passing VM_IOREMAP to vmap(). This will tell vread() to not include the ramoops region in the kcore. Instead the area will look like a bunch of zeros. The alternative is to teach kmap() about vmalloc areas that intersect with lowmem. Presumably such a change isn't a one-liner, and there isn't much interest in inspecting the ramoops region in kcore files anyway, so the most expedient route is taken for now. (CVE-2022-50849)
- 已修复 Linux 内核中的下列漏洞：hwrng: amd - Fix PCI device refcount leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the normal and error path. (CVE-2022-50868)
- 已修复 Linux 内核中的下列漏洞：RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. (CVE-2023-52515)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 CENTOS7：CLSA-2026：1792976962 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 374124
文件名: tuxcare_centos_7_CLSA-2026-1792976962.nasl
版本: 1.1
类型: Local
代理: unix
发布时间: 2026/10/30
最近更新时间: 2026/10/30
支持的传感器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: High
分数: 7.9
百分位: 99.34
Vendor
Vendor Severity: Important
CVSS v2
风险因素: Medium
基本分数: 6.8
时间分数: 5
矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 分数来源: CVE-2026-46294
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/21
参考资料信息
CVE: CVE-2022-50709, CVE-2022-50751, CVE-2022-50849, CVE-2022-50868, CVE-2023-52515, CVE-2023-53754, CVE-2023-53802, CVE-2023-53831, CVE-2023-54067, CVE-2023-54284, CVE-2024-47713, CVE-2024-50076, CVE-2024-50289, CVE-2026-45920, CVE-2026-46294, CVE-2026-53392, CVE-2026-63904, CVE-2026-63916, CVE-2026-63917, CVE-2026-63921, CVE-2026-63990, CVE-2026-64115, CVE-2026-64276, CVE-2026-64351, CVE-2026-64465, CVE-2026-68118, CVE-2026-68146, CVE-2026-68326, CVE-2026-68377, CVE-2026-68405, CVE-2026-68428, CVE-2026-68436, CVE-2026-72017, CVE-2026-72021, CVE-2026-72108, CVE-2026-72238, CVE-2026-72243, CVE-2026-72250, CVE-2026-72251, CVE-2026-72284, CVE-2026-72319, CVE-2026-72321, CVE-2026-72322, CVE-2026-72350, CVE-2026-72392, CVE-2026-72421, CVE-2026-74271, CVE-2026-74330, CVE-2026-74388, CVE-2026-74417, CVE-2026-74485, CVE-2026-74544, CVE-2026-80628, CVE-2026-80659, CVE-2026-80664, CVE-2026-80689, CVE-2026-80706, CVE-2026-80765, CVE-2026-80783, CVE-2026-80785, CVE-2026-80819, CVE-2026-80824, CVE-2026-80827, CVE-2026-80828, CVE-2026-80847, CVE-2026-80875, CVE-2026-80912, CVE-2026-80973, CVE-2026-80977, CVE-2026-89485, CVE-2026-89515, CVE-2026-89527, CVE-2026-89540, CVE-2026-89541, CVE-2026-89559, CVE-2026-89595, CVE-2026-89628, CVE-2026-89631, CVE-2026-89638, CVE-2026-89659, CVE-2026-89666, CVE-2026-89672, CVE-2026-89722, CVE-2026-89783, CVE-2026-89784, CVE-2026-89965, CVE-2026-90103, CVE-2026-90151, CVE-2026-90235, CVE-2026-90293, CVE-2026-90294, CVE-2026-90307, CVE-2026-90345, CVE-2026-90383, CVE-2026-92499, CVE-2026-93048, CVE-2026-93140, CVE-2026-93206, CVE-2026-93251, CVE-2026-93793, CVE-2026-97518, CVE-2026-97561, CVE-2026-97929, CVE-2026-97930, CVE-2026-97938, CVE-2026-98015, CVE-2026-98099, CVE-2026-98176, CVE-2026-98177, CVE-2026-98186, CVE-2026-98357, CVE-2026-98358, CVE-2026-98359, CVE-2026-98486, CVE-2026-98488, CVE-2026-98489, CVE-2026-98494, CVE-2026-98501
CLSA: 2026:1792976962