CVE-2023-53778 (GCVE-0-2023-53778)
Vulnerability from cvelistv5
Published
2025-12-09 00:00
Modified
2026-08-05 09:15
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Clean up integer overflow checking in map_user_pages() The encode_dma() function has some validation on in_trans->size but it would be more clear to move those checks to find_and_map_user_pages(). The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL; The in_trans->addr variable is the starting address. The in_trans->size variable is the total size of the transfer. The transfer can occur in parts and the resources->xferred_dma_size tracks how many bytes we have already transferred. This patch introduces a new variable "remaining" which represents the amount we want to transfer (in_trans->size) minus the amount we have already transferred (resources->xferred_dma_size). I have modified the check for if in_trans->size is zero to instead check if in_trans->size is less than resources->xferred_dma_size. If we have already transferred more bytes than in_trans->size then there are negative bytes remaining which doesn't make sense. If there are zero bytes remaining to be copied, just return success. The check in encode_dma() checked that "addr + size" could not overflow and barring a driver bug that should work, but it's easier to check if we do this in parts. First check that "in_trans->addr + resources->xferred_dma_size" is safe. Then check that "xfer_start_addr + remaining" is safe. My final concern was that we are dealing with u64 values but on 32bit systems the kmalloc() function will truncate the sizes to 32 bits. So I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);" and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bit systems.
References
Impacted products
Vendor Product Version
Linux Linux Version: 129776ac2e38231fa9c02ce20e116c99de291666
Version: 129776ac2e38231fa9c02ce20e116c99de291666
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/accel/qaic/qaic_control.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3",
              "status": "affected",
              "version": "129776ac2e38231fa9c02ce20e116c99de291666",
              "versionType": "git"
            },
            {
              "lessThan": "96d3c1cadedb6ae2e8965e19cd12caa244afbd9c",
              "status": "affected",
              "version": "129776ac2e38231fa9c02ce20e116c99de291666",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/accel/qaic/qaic_control.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.4"
            },
            {
              "lessThan": "6.4",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.4.*",
              "status": "unaffected",
              "version": "6.4.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.5",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.4.12",
                  "versionStartIncluding": "6.4",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5",
                  "versionStartIncluding": "6.4",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: Clean up integer overflow checking in map_user_pages()\n\nThe encode_dma() function has some validation on in_trans-\u003esize but it\nwould be more clear to move those checks to find_and_map_user_pages().\n\nThe encode_dma() had two checks:\n\n\tif (in_trans-\u003eaddr + in_trans-\u003esize \u003c in_trans-\u003eaddr || !in_trans-\u003esize)\n\t\treturn -EINVAL;\n\nThe in_trans-\u003eaddr variable is the starting address.  The in_trans-\u003esize\nvariable is the total size of the transfer.  The transfer can occur in\nparts and the resources-\u003exferred_dma_size tracks how many bytes we have\nalready transferred.\n\nThis patch introduces a new variable \"remaining\" which represents the\namount we want to transfer (in_trans-\u003esize) minus the amount we have\nalready transferred (resources-\u003exferred_dma_size).\n\nI have modified the check for if in_trans-\u003esize is zero to instead check\nif in_trans-\u003esize is less than resources-\u003exferred_dma_size.  If we have\nalready transferred more bytes than in_trans-\u003esize then there are negative\nbytes remaining which doesn\u0027t make sense.  If there are zero bytes\nremaining to be copied, just return success.\n\nThe check in encode_dma() checked that \"addr + size\" could not overflow\nand barring a driver bug that should work, but it\u0027s easier to check if\nwe do this in parts.  First check that \"in_trans-\u003eaddr +\nresources-\u003exferred_dma_size\" is safe.  Then check that \"xfer_start_addr +\nremaining\" is safe.\n\nMy final concern was that we are dealing with u64 values but on 32bit\nsystems the kmalloc() function will truncate the sizes to 32 bits.  So\nI calculated \"total = in_trans-\u003esize + offset_in_page(xfer_start_addr);\"\nand returned -EINVAL if it were \u003e= SIZE_MAX.  This will not affect 64bit\nsystems."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The vulnerability is reached only through the DRM_IOCTL_QAIC_MANAGE ioctl on the local accelerator character device /dev/accel/accelN; the malformed transaction list is copied in from local userspace via copy_from_user() in qaic_manage_ioctl(). No network or adjacent-network path exists.\nAC:L - The attacker fully controls addr, size and the number of DMA transactions in a single 4K manage message, and the arithmetic underflow/zero-page-count condition is deterministic \u2014 two page-aligned 4096-byte transfer transactions reliably drive need_pages to 0 on every attempt with no race or layout dependency.\nPR:L - The QAIC ioctls are registered with flags 0 (no DRM_ROOT_ONLY, no DRM_AUTH) and qaic_open() performs no capability check, so any unprivileged local user or container workload holding an open handle on the accel node \u2014 which systemd tags with uaccess and which inference stacks routinely expose to non-root service accounts \u2014 can trigger it.\nUI:N - The attacker issues the ioctl directly from their own process; no victim action, no file to be opened, and no privileged helper needs to be induced into doing anything.\nS:U - The corruption and the crash occur entirely within the kernel\u0027s own security authority on the host; the DMA mapping is DMA_TO_DEVICE over pages the attacker already owns, so no IOMMU, hypervisor, or sandbox boundary is crossed.\nC:H - The unchecked arithmetic makes the computed page count and the byte count handed to sg_alloc_table_from_pages()/dma_map_sgtable() diverge (need_pages is an unsigned long derived from u64 user input, and the sg API\u0027s size parameter is unsigned long, truncating on 32-bit), and the resulting wild ZERO_SIZE_PTR page-array dereference is an uncontrolled pointer read into DMA descriptor construction, which must be treated as an arbitrary-read-class exposure.\nI:H - The same page-count/byte-count mismatch feeds get_user_pages_fast() and the scatter-gather table that the device firmware consumes, so the descriptor set can be built from a page array sized by a different, overflowed value \u2014 an integer-overflow memory-safety condition of the class that yields out-of-bounds write primitives, which is precisely why the fix added check_add_overflow() and the SIZE_MAX guard.\nA:H - An unprivileged ioctl deterministically causes a near-NULL (0x10) pointer dereference and kernel oops inside sg_alloc_append_table_from_pages(), leaking two SRCU read sections so subsequent device reset/removal deadlocks, and the underflow variant pins and DMA-maps ~2 GB of memory per repeatable call, exhausting system memory."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T09:15:57.518Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3"
        },
        {
          "url": "https://git.kernel.org/stable/c/96d3c1cadedb6ae2e8965e19cd12caa244afbd9c"
        }
      ],
      "title": "accel/qaic: Clean up integer overflow checking in map_user_pages()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-53778",
    "datePublished": "2025-12-09T00:00:34.074Z",
    "dateReserved": "2025-12-08T23:58:35.272Z",
    "dateUpdated": "2026-08-05T09:15:57.518Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


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.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • 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.