AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點 （ALMALINUX9.2：CLSA-2024：1728936982）
high Nessus Plugin ID 353076
語言:
概要
AlmaLinux 主機缺少一或多個安全性更新。說明
AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2024：1728936982 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：tty: Fix out-of-bound vmalloc access in imageblit This issue happens when a userspace program does an ioctl FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct containing only the fields xres, yres, and bits_per_pixel with values. If this struct is the same as the previous ioctl, the vc_resize() detects it and doesn't call the resize_screen(), leaving the fb_var_screeninfo incomplete. And this leads to the updatescrollmode() calculates a wrong value to fbcon_display->vrows, which makes the real_y() return a wrong value of y, and that value, eventually, causes the imageblit to access an out-of-bound address value. To solve this issue I made the resize_screen() be called even if the screen does not need any resizing, so it will fix and fill the fb_var_screeninfo independently. (CVE-2021-47383)
- 已解決 Linux 核心中的下列弱點：seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 (ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation) a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 (ipv6: When forwarding count rx stats on the orig netdev) is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again. (CVE-2021-47515)
- 在 Linux 核心的 cxgb4 驅動程式中發現釋放後使用弱點。此錯誤會在 cxgb4 裝置因工作佇列中可能重新配置的 Flower_stats_timer 而中斷卸離時發生。本機使用者可利用此缺陷使系統當機，進而引發拒絕服務情形。(CVE-2023-4133)
- 在 Linux 核心的 TUN/TAP 功能中發現一個缺陷。本機使用者可利用此問題繞過網路篩選器，並在未經授權的情況下存取某些資源。修正 CVE-2023-1076 的原始修補程式不正確或不完整。問題在於下列上游 commit - a096ccca6e50 (tun：tun_chr_open()：正確初始化通訊端 uid)、- 66b2c338adce (tap：tap_open()：
正確初始化通訊端 uid)，將 inode->i_uid 作為最後一個參數傳遞至 sock_init_data_uid()，而事實證明這不正確。(CVE-2023-4194)
- 已解決 Linux 核心中的下列弱點：bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/[email protected]/(CVE-2023-52735)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 ALMALINUX9.2：CLSA-2024：1728936982 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 353076
檔案名稱: tuxcare_alma_linux_9.2_CLSA-2024-1728936982.nasl
版本: 1.1
類型: Local
已發布: 2026/9/30
已更新: 2026/9/30
支援的感應器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: High
分數: 7.6
百分位數: 98.67
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-2024-46859
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/OS/extended-third-party, Host/local_checks_enabled, Host/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2024/10/14
弱點發布日期: 2021/7/21
參考資訊
CVE: CVE-2021-47383, CVE-2021-47515, CVE-2023-4133, CVE-2023-4194, CVE-2023-52651, CVE-2023-52735, CVE-2023-52880, CVE-2023-52884, CVE-2024-26629, CVE-2024-26665, CVE-2024-26737, CVE-2024-26853, CVE-2024-26855, CVE-2024-26931, CVE-2024-26946, CVE-2024-27016, CVE-2024-27030, CVE-2024-27046, CVE-2024-27052, CVE-2024-27415, CVE-2024-35789, CVE-2024-35791, CVE-2024-35845, CVE-2024-35852, CVE-2024-35895, CVE-2024-35898, CVE-2024-36025, CVE-2024-36899, CVE-2024-36941, CVE-2024-36979, CVE-2024-38559, CVE-2024-38562, CVE-2024-38579, CVE-2024-38588, CVE-2024-38601, CVE-2024-38619, CVE-2024-38627, CVE-2024-39476, CVE-2024-40905, CVE-2024-40911, CVE-2024-40912, CVE-2024-40914, CVE-2024-40927, CVE-2024-40929, CVE-2024-40941, CVE-2024-40978, CVE-2024-40983, CVE-2024-40995, CVE-2024-41013, CVE-2024-41023, CVE-2024-41039, CVE-2024-41041, CVE-2024-41044, CVE-2024-41071, CVE-2024-41076, CVE-2024-41096, CVE-2024-42082, CVE-2024-42096, CVE-2024-42110, CVE-2024-42131, CVE-2024-42136, CVE-2024-42148, CVE-2024-42152, CVE-2024-42243, CVE-2024-43882, CVE-2024-46700, CVE-2024-46722, CVE-2024-46723, CVE-2024-46724, CVE-2024-46725, CVE-2024-46731, CVE-2024-46738, CVE-2024-46743, CVE-2024-46744, CVE-2024-46746, CVE-2024-46747, CVE-2024-46756, CVE-2024-46757, CVE-2024-46758, CVE-2024-46759, CVE-2024-46800, CVE-2024-46811, CVE-2024-46813, CVE-2024-46818, CVE-2024-46821, CVE-2024-46859
CLSA: 2024:1728936982