• 公告ID (KylinSec-SA-2024-4892)

摘要:

kernel security update

安全等级: Critical

公告ID: KylinSec-SA-2024-4892

发布日期: 2025年2月17日

关联CVE: CVE-2024-38612   CVE-2024-44952   CVE-2024-46757   CVE-2024-46826  

  • 详细介绍

1. 漏洞描述

   

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix invalid unregister error path

The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL
is not defined. In that case if seg6_hmac_init() fails, the
genl_unregister_family() isn't called.

This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control
lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible
use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()
with genl_unregister_family() in this error path.(CVE-2024-38612)

In the Linux kernel, the following vulnerability has been resolved:

driver core: Fix uevent_show() vs driver detach race

uevent_show() wants to de-reference dev->driver->name. There is no clean
way for a device attribute to de-reference dev->driver unless that
attribute is defined via (struct device_driver).dev_groups. Instead, the
anti-pattern of taking the device_lock() in the attribute handler risks
deadlocks with code paths that remove device attributes while holding
the lock.

This deadlock is typically invisible to lockdep given the device_lock()
is marked lockdep_set_novalidate_class(), but some subsystems allocate a
local lockdep key for @dev->mutex to reveal reports of the form:

======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc7+ #275 Tainted: G OE N
------------------------------------------------------
modprobe/2374 is trying to acquire lock:
ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220

but task is already holding lock:
ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&cxl_root_key){+.+.}-{3:3}:
__mutex_lock+0x99/0xc30
uevent_show+0xac/0x130
dev_attr_show+0x18/0x40
sysfs_kf_seq_show+0xac/0xf0
seq_read_iter+0x110/0x450
vfs_read+0x25b/0x340
ksys_read+0x67/0xf0
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #0 (kn->active#6){++++}-{0:0}:
__lock_acquire+0x121a/0x1fa0
lock_acquire+0xd6/0x2e0
kernfs_drain+0x1e9/0x200
__kernfs_remove+0xde/0x220
kernfs_remove_by_name_ns+0x5e/0xa0
device_del+0x168/0x410
device_unregister+0x13/0x60
devres_release_all+0xb8/0x110
device_unbind_cleanup+0xe/0x70
device_release_driver_internal+0x1c7/0x210
driver_detach+0x47/0x90
bus_remove_driver+0x6c/0xf0
cxl_acpi_exit+0xc/0x11 [cxl_acpi]
__do_sys_delete_module.isra.0+0x181/0x260
do_syscall_64+0x75/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e

The observation though is that driver objects are typically much longer
lived than device objects. It is reasonable to perform lockless
de-reference of a @driver pointer even if it is racing detach from a
device. Given the infrequency of driver unregistration, use
synchronize_rcu() in module_remove_driver() to close any potential
races. It is potentially overkill to suffer synchronize_rcu() just to
handle the rare module removal racing uevent_show() event.

Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952)

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (nct6775-core) Fix underflows seen when writing limit attributes

DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)

In the Linux kernel, the following vulnerability has been resolved:

ELF: fix kernel.randomize_va_space double read

ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.

Issue exactly one load for consistent value across one exec.(CVE-2024-46826)

2. 影响范围

cve名称 产品 组件 是否受影响
CVE-2024-38612 KY3.4-5 kernel Fixed
CVE-2024-44952 KY3.4-5 kernel Fixed
CVE-2024-46757 KY3.4-5 kernel Fixed
CVE-2024-46826 KY3.4-5 kernel Fixed

3. 影响组件

    kernel

4. 修复版本

   

KY3.4-5

软件名称 架构 版本号
python3-perf x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
bpftool x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-devel x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-tools-devel x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
python2-perf x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
perf x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-tools x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-source x86_64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-tools-devel aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-tools aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
python3-perf aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
python2-perf aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
bpftool aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-devel aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
kernel-source aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4
perf aarch64 4.19.90-2408.1.0.0288.kb2.ky3_4

5. 修复方法


方法一:下载安装包进行升级安装
1、通过下载链接下载需要升级的升级包保存,如 xxx.rpm
2、通过rpm命令升级,如 rpm -Uvh xxx.rpm

方法二:通过软件源进行升级安装
1、保持能够连接上互联网
2、通过yum命令升级指定的包,如 yum install 包名

6. 下载链接

   

KY3.4-5:

x86_64:

     python3-perf   

     bpftool   

     kernel   

     kernel-devel   

     kernel-tools-devel   

     python2-perf   

     perf   

     kernel-tools   

     kernel-source   

aarch64:

     kernel   

     kernel-tools-devel   

     kernel-tools   

     python3-perf   

     python2-perf   

     bpftool   

     kernel-devel   

     kernel-source   

     perf   

上一篇:KylinSec-SA-2024-4883 下一篇:KylinSec-SA-2024-4896