ghsa-frfp-g383-4xwm
Vulnerability from github
Published
2025-09-16 18:31
Modified
2025-09-16 18:31
Details

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

cifs: fix oops during encryption

When running xfstests against Azure the following oops occurred on an arm64 system

Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0

This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary.

To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov...

Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-50341"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T17:15:33Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix oops during encryption\n\nWhen running xfstests against Azure the following oops occurred on an\narm64 system\n\n  Unable to handle kernel write to read-only memory at virtual address\n  ffff0001221cf000\n  Mem abort info:\n    ESR = 0x9600004f\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x0f: level 3 permission fault\n  Data abort info:\n    ISV = 0, ISS = 0x0000004f\n    CM = 0, WnR = 1\n  swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000\n  [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,\n  pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787\n  Internal error: Oops: 9600004f [#1] PREEMPT SMP\n  ...\n  pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)\n  pc : __memcpy+0x40/0x230\n  lr : scatterwalk_copychunks+0xe0/0x200\n  sp : ffff800014e92de0\n  x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008\n  x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008\n  x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000\n  x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014\n  x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058\n  x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590\n  x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580\n  x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005\n  x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001\n  x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000\n  Call trace:\n   __memcpy+0x40/0x230\n   scatterwalk_map_and_copy+0x98/0x100\n   crypto_ccm_encrypt+0x150/0x180\n   crypto_aead_encrypt+0x2c/0x40\n   crypt_message+0x750/0x880\n   smb3_init_transform_rq+0x298/0x340\n   smb_send_rqst.part.11+0xd8/0x180\n   smb_send_rqst+0x3c/0x100\n   compound_send_recv+0x534/0xbc0\n   smb2_query_info_compound+0x32c/0x440\n   smb2_set_ea+0x438/0x4c0\n   cifs_xattr_set+0x5d4/0x7c0\n\nThis is because in scatterwalk_copychunks(), we attempted to write to\na buffer (@sign) that was allocated in the stack (vmalloc area) by\ncrypt_message() and thus accessing its remaining 8 (x2) bytes ended up\ncrossing a page boundary.\n\nTo simply fix it, we could just pass @sign kmalloc\u0027d from\ncrypt_message() and then we\u0027re done.  Luckily, we don\u0027t seem to pass\nany other vmalloc\u0027d buffers in smb_rqst::rq_iov...\n\nInstead, let\u0027s map the correct pages and offsets from vmalloc buffers\nas well in cifs_sg_set_buf() and then avoiding such oopses.",
  "id": "GHSA-frfp-g383-4xwm",
  "modified": "2025-09-16T18:31:25Z",
  "published": "2025-09-16T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50341"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a13e51760703f71c25d5fc1f4a62dfa4b0cc80e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf0543b93740916ee91956f9a63da6fc0d79daaa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8d16a54842d609fd4a3ed2d81d4333d6329aa94"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8e2861cc3258dbe407d01ea8c59bb5a53132301"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7f291e14dde32a07b1f0aa06921d28f875a7b54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe6ea044c4f05706cb71040055b1c70c6c8275e0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.