CentOS Linux 8.5 [TuxCare] 安全性更新:bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點 (CENTOS8.5:CLSA-2025:1763734783)

high Nessus Plugin ID 352076

概要

CentOS Linux 主機缺少一個或多個安全性更新。

說明

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

- 已解決 Linux 核心中的下列弱點:scsi: mpt3sas: Fix use-after-free warning Fix the following use-after-free warning which is observed during controller reset: refcount_t:
underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 (CVE-2022-48695)

- 已解決 Linux 核心中的下列弱點:ASoC: ops: Reject out of bounds values in snd_soc_put_volsw() We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
(CVE-2022-48738)

- 已解決 Linux 核心中的下列弱點:rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint:
delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26 [93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc :
debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp :
ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27:
ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20:
ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17:
0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10:
0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 :
0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 :
0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963]
__debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda (chardev: add helper function to register char devs with a struct device)'), use it instead of cdev add/del(). (CVE-2022-48759)

- 已解決 Linux 核心中的下列弱點:dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the tag_size parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array. (CVE-2022-49044)

- 已解決 Linux 核心中的下列弱點:ata: sata_dwc_460ex: Fix crash due to OOB write the driver uses libata's tag values from in various arrays. Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32, the value of the SATA_DWC_QCMD_MAX needs to account for that. Otherwise ATA_TAG_INTERNAL usage cause similar crashes like this as reported by Tice Rex on the OpenWrt Forum and reproduced (with symbols) here: | BUG: Kernel NULL pointer dereference at 0x00000000 | Faulting instruction address: 0xc03ed4b8 | Oops: Kernel access of bad area, sig: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR:
c03ed36c | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) | MSR: 00021000 <CE,ME> CR: 42000222 XER:
00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254 | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc | Call Trace: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...] This is because sata_dwc_dma_xfer_complete() NULLs the dma_pending's next neighbour chan (a *dma_chan struct) in this '32' case right here (line ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Then the next time, a dma gets issued;
dma_dwc_xfer_setup() passes the NULL'd hsdevp->chan to the dmaengine_slave_config() which then causes the crash. With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1. This avoids the OOB. But please note, there was a worthwhile discussion on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not be a fake 33 command-long queue size. Ideally, the dw driver should account for the ATA_TAG_INTERNAL. In Damien Le Moal's words: ... having looked at the driver, it is a bigger change than just faking a 33rd tag that is in fact not a command tag at all. BugLink:
https://github.com/openwrt/openwrt/issues/9505 (CVE-2022-49073)

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

解決方案

根據 TuxCare 公告 CENTOS8.5:CLSA-2025:1763734783 中的指引更新受影響的套件。

另請參閱

https://cve.tuxcare.com/els/releases/CLSA-2025:1763734783

http://www.nessus.org/u?cff2c7e1

Plugin 詳細資訊

嚴重性: High

ID: 352076

檔案名稱: tuxcare_centos_8.5_CLSA-2025-1763734783.nasl

版本: 1.1

類型: Local

代理程式: unix

已發布: 2026/9/30

已更新: 2026/9/30

支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

風險資訊

VPR

風險因素: High

分數: 7

百分位數: 98.57

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-2025-39864

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

修補程式發佈日期: 2025/11/21

弱點發布日期: 2021/7/21

參考資訊

CVE: CVE-2022-48695, CVE-2022-48738, CVE-2022-48759, CVE-2022-49044, CVE-2022-49073, CVE-2022-49145, CVE-2022-49292, CVE-2022-49407, CVE-2022-49519, CVE-2022-49592, CVE-2022-49935, CVE-2022-49985, CVE-2022-50087, CVE-2022-50228, CVE-2022-50367, CVE-2022-50408, CVE-2023-52804, CVE-2023-52836, CVE-2023-52847, CVE-2023-52867, CVE-2023-52868, CVE-2023-53019, CVE-2023-53034, CVE-2023-53125, CVE-2023-53178, CVE-2023-53185, CVE-2023-53226, CVE-2023-53229, CVE-2023-53297, CVE-2023-53322, CVE-2023-53365, CVE-2023-53373, CVE-2023-53386, CVE-2023-53581, CVE-2023-53675, CVE-2023-53705, CVE-2024-36015, CVE-2024-38621, CVE-2024-38635, CVE-2024-38659, CVE-2024-42119, CVE-2024-46713, CVE-2024-52332, CVE-2024-53214, CVE-2024-56570, CVE-2024-57904, CVE-2024-57929, CVE-2024-58014, CVE-2024-58072, CVE-2025-21704, CVE-2025-21772, CVE-2025-22121, CVE-2025-37789, CVE-2025-37796, CVE-2025-38001, CVE-2025-38461, CVE-2025-38498, CVE-2025-38527, CVE-2025-38718, CVE-2025-39730, CVE-2025-39757, CVE-2025-39817, CVE-2025-39841, CVE-2025-39864

CLSA: 2025:1763734783