摘要:
kernel security update
安全等级: High
公告ID: KylinSec-SA-2025-2776
发布日期: 2025年7月13日
关联CVE: CVE-2022-49870 CVE-2025-37995 CVE-2025-37834 CVE-2022-21546 CVE-2023-53051
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Fix WRITE_SAME No Data Buffer crash
In newer version of the SBC specs, we have a NDOB bit that indicates there
is no data buffer that gets written out. If this bit is set using commands
like "sg_write_same --ndob" we will crash in target_core_iblock/file's
execute_write_same handlers when we go to access the se_cmd->t_data_sg
because its NULL.
This patch adds a check for the NDOB bit in the common WRITE SAME code
because we don't support it. And, it adds a check for zero SG elements in
each handler in case the initiator tries to send a normal WRITE SAME with
no data buffer.(CVE-2022-21546)
In the Linux kernel, the following vulnerability has been resolved:
capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xa5
dump_stack+0x15/0x1b
ubsan_epilogue+0xe/0x4e
__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
cap_task_prctl+0x561/0x6f0
security_task_prctl+0x5a/0xb0
__x64_sys_prctl+0x61/0x8f0
do_syscall_64+0x58/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>(CVE-2022-49870)
In the Linux kernel, the following vulnerability has been resolved:
dm crypt: add cond_resched() to dmcrypt_write()
The loop in dmcrypt_write may be running for unbounded amount of time,
thus we need cond_resched() in it.
This commit fixes the following warning:
[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]
...
[ 3391.387210][ C12] Call trace:
[ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158
[ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0
[ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550
[ 3391.405856][ C12] submit_bio_noacct+0x308/0x380
[ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt]
[ 3391.416005][ C12] kthread+0x130/0x138
[ 3391.419911][ C12] ret_from_fork+0x10/0x18(CVE-2023-53051)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000
Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users
Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed
page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e
memcg:ffff0000dd6d9000
anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)
raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9
raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000
page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))
------------[ cut here ]------------
kernel BUG at mm/swap_state.c:184!
Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
Modules linked in:
CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : add_to_swap+0xbc/0x158
lr : add_to_swap+0xbc/0x158
sp : ffff800087f37340
x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780
x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0
x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4
x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000
x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c
x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b
x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000
x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001
x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000
Call trace:
add_to_swap+0xbc/0x158
shrink_folio_list+0x12ac/0x2648
shrink_inactive_list+0x318/0x948
shrink_lruvec+0x450/0x720
shrink_node_memcgs+0x280/0x4a8
shrink_node+0x128/0x978
balance_pgdat+0x4f0/0xb20
kswapd+0x228/0x438
kthread+0x214/0x230
ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the
page isn't locked, inject memory failure for the page.
me_swapcache_dirty() clears uptodate flag and tries to delete from lru,
but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted
the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page,
add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is
cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the
hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap
it in shrink_folio_list(), otherwise the folio will fail to be unmaped by
hwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)
In the Linux kernel, the following vulnerability has been resolved:
module: ensure that kobject_put() is safe for module type kobjects
In 'lookup_or_create_module_kobject()', an internal kobject is created
using 'module_ktype'. So call to 'kobject_put()' on error handling
path causes an attempt to use an uninitialized completion pointer in
'module_kobject_release()'. In this scenario, we just want to release
kobject without an extra synchronization required for a regular module
unloading process, so adding an extra check whether 'complete()' is
actually required makes 'kobject_put()' safe.(CVE-2025-37995)
cve名称 | 产品 | 组件 | 是否受影响 |
---|---|---|---|
CVE-2022-49870 | KY3.4-5A | kernel | Fixed |
CVE-2025-37995 | KY3.4-5A | kernel | Fixed |
CVE-2025-37834 | KY3.4-5A | kernel | Fixed |
CVE-2022-21546 | KY3.4-5A | kernel | Fixed |
CVE-2023-53051 | KY3.4-5A | kernel | Fixed |
软件名称 | 架构 | 版本号 |
---|---|---|
bpftool | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-devel | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-source | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-tools | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-tools-devel | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
perf | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
python2-perf | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
python3-perf | x86_64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
bpftool | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-devel | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-source | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-tools | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
kernel-tools-devel | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
perf | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
python2-perf | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
python3-perf | aarch64 | 4.19.90-2408.1.0.0288.kb28.ky3_4 |
方法一:下载安装包进行升级安装
1、通过下载链接下载需要升级的升级包保存,如 xxx.rpm
2、通过rpm命令升级,如 rpm -Uvh xxx.rpm
方法二:通过软件源进行升级安装
1、保持能够连接上互联网
2、通过yum命令升级指定的包,如 yum install 包名