GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-1626 (CVE-2022-21546)

Vulnerability from osv_openeuler – Published: 2025-06-13 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
Summary
kernel security update
Details

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)

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2506.2.0.0331.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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)",
  "id": "OESA-2025-1626",
  "modified": "2026-08-06T11:08:43Z",
  "published": "2025-06-13T11:08:43Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-21546",
    "CVE-2022-49870",
    "CVE-2023-53051",
    "CVE-2025-37834",
    "CVE-2025-37995"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.