{"schema_version":"1.7.2","id":"OESA-2025-1626","modified":"2025-06-13T14:19:51Z","published":"2025-06-13T14:19:51Z","upstream":["CVE-2022-21546","CVE-2022-49870","CVE-2023-53051","CVE-2025-37834","CVE-2025-37995"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix WRITE_SAME No Data Buffer crash\n\nIn newer version of the SBC specs, we have a NDOB bit that indicates there\nis no data buffer that gets written out. If this bit is set using commands\nlike \u0026quot;sg_write_same --ndob\u0026quot; we will crash in target_core_iblock/file\u0026apos;s\nexecute_write_same handlers when we go to access the se_cmd-\u0026gt;t_data_sg\nbecause its NULL.\n\nThis patch adds a check for the NDOB bit in the common WRITE SAME code\nbecause we don\u0026apos;t support it. And, it adds a check for zero SG elements in\neach handler in case the initiator tries to send a normal WRITE SAME with\nno data buffer.(CVE-2022-21546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncapabilities: fix undefined behavior in bit shift for CAP_TO_MASK\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in security/commoncap.c:1252:2\nleft shift of 1 by 31 places cannot be represented in type \u0026apos;int\u0026apos;\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n cap_task_prctl+0x561/0x6f0\n security_task_prctl+0x5a/0xb0\n __x64_sys_prctl+0x61/0x8f0\n do_syscall_64+0x58/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n \u0026lt;/TASK\u0026gt;(CVE-2022-49870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm crypt: add cond_resched() to dmcrypt_write()\n\nThe loop in dmcrypt_write may be running for unbounded amount of time,\nthus we need cond_resched() in it.\n\nThis commit fixes the following warning:\n\n[ 3391.153255][   C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]\n...\n[ 3391.387210][   C12] Call trace:\n[ 3391.390338][   C12]  blk_attempt_bio_merge.part.6+0x38/0x158\n[ 3391.395970][   C12]  blk_attempt_plug_merge+0xc0/0x1b0\n[ 3391.401085][   C12]  blk_mq_submit_bio+0x398/0x550\n[ 3391.405856][   C12]  submit_bio_noacct+0x308/0x380\n[ 3391.410630][   C12]  dmcrypt_write+0x1e4/0x208 [dm_crypt]\n[ 3391.416005][   C12]  kthread+0x130/0x138\n[ 3391.419911][   C12]  ret_from_fork+0x10/0x18(CVE-2023-53051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0026apos;t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n   page isn\u0026apos;t locked, inject memory failure for the page. \n   me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n   but fails.  Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n   the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n   add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n   cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0026apos;t in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmodule: ensure that kobject_put() is safe for module type kobjects\n\nIn \u0026apos;lookup_or_create_module_kobject()\u0026apos;, an internal kobject is created\nusing \u0026apos;module_ktype\u0026apos;. So call to \u0026apos;kobject_put()\u0026apos; on error handling\npath causes an attempt to use an uninitialized completion pointer in\n\u0026apos;module_kobject_release()\u0026apos;. In this scenario, we just want to release\nkobject without an extra synchronization required for a regular module\nunloading process, so adding an extra check whether \u0026apos;complete()\u0026apos; is\nactually required makes \u0026apos;kobject_put()\u0026apos; safe.(CVE-2025-37995)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2506.2.0.0331.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","perf-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2506.2.0.0331.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","perf-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2506.2.0.0331.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1626"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-21546"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37995"}],"database_specific":{"severity":"High"}}