fkie_cve-2022-48762
Vulnerability from fkie_nvd
Published
2024-06-20 12:15
Modified
2025-03-24 18:17
Severity ?
6.2 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MTE-enabled QEMU image we are hitting the following crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0xf4 el1_abort+0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_sys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239aPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3ebPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239aPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3ebPatch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel 5.17


To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "1AD9E77E-B27E-450C-8FD8-B64EC5FB002D",
              "versionEndExcluding": "5.16.5",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: extable: fix load_unaligned_zeropad() reg indices\n\nIn ex_handler_load_unaligned_zeropad() we erroneously extract the data and\naddr register indices from ex-\u003etype rather than ex-\u003edata. As ex-\u003etype will\ncontain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):\n * We\u0027ll always treat X0 as the address register, since EX_DATA_REG_ADDR is\n   extracted from bits [9:5]. Thus, we may attempt to dereference an\n   arbitrary address as X0 may hold an arbitrary value.\n * We\u0027ll always treat X4 as the data register, since EX_DATA_REG_DATA is\n   extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary\n   behaviour within load_unaligned_zeropad() and its caller.\n\nFix this by extracting both values from ex-\u003edata as originally intended.\n\nOn an MTE-enabled QEMU image we are hitting the following crash:\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Call trace:\n  fixup_exception+0xc4/0x108\n  __do_kernel_fault+0x3c/0x268\n  do_tag_check_fault+0x3c/0x104\n  do_mem_abort+0x44/0xf4\n  el1_abort+0x40/0x64\n  el1h_64_sync_handler+0x60/0xa0\n  el1h_64_sync+0x7c/0x80\n  link_path_walk+0x150/0x344\n  path_openat+0xa0/0x7dc\n  do_filp_open+0xb8/0x168\n  do_sys_openat2+0x88/0x17c\n  __arm64_sys_openat+0x74/0xa0\n  invoke_syscall+0x48/0x148\n  el0_svc_common+0xb8/0xf8\n  do_el0_svc+0x28/0x88\n  el0_svc+0x24/0x84\n  el0t_64_sync_handler+0x88/0xec\n  el0t_64_sync+0x1b4/0x1b8\n Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: extable: corrige los \u00edndices de registro load_unaligned_zeropad() En ex_handler_load_unaligned_zeropad() extraemos err\u00f3neamente los datos y los \u00edndices de registro de direcciones de ex-\u0026gt;type en lugar de ex-\u0026gt;data. Como ex-\u0026gt;type contendr\u00e1 EX_TYPE_LOAD_UNALIGNED_ZEROPAD (es decir, 4): * Siempre trataremos a X0 como el registro de direcci\u00f3n, ya que EX_DATA_REG_ADDR se extrae de los bits [9:5]. Por lo tanto, podemos intentar eliminar la referencia a una direcci\u00f3n arbitraria ya que X0 puede tener un valor arbitrario. * Siempre trataremos a X4 como el registro de datos, ya que EX_DATA_REG_DATA se extrae de los bits [4:0]. Por lo tanto, corromperemos X4 y provocaremos un comportamiento arbitrario dentro de load_unaligned_zeropad() y su llamador. Solucione este problema extrayendo ambos valores de ex-\u0026gt;data como se pretend\u00eda originalmente. En una imagen QEMU habilitada para MTE, nos encontramos con el siguiente bloqueo: No se puede manejar la desreferencia del puntero NULL del kernel en la direcci\u00f3n virtual 0000000000000000 Rastreo de llamadas: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0 xf4 el1_abort+ 0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_s ys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+ 0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 C\u00f3digo: f8695a69 71007d1f 540000e0 927df12a (f940014a)"
    }
  ],
  "id": "CVE-2022-48762",
  "lastModified": "2025-03-24T18:17:02.420",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 6.2,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.5,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ]
  },
  "published": "2024-06-20T12:15:14.287",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239a"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


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.