Skip to content
CVE Tracker
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API documentationPage
  • MCP serverPage
  • Data sourcesPage
  • ChangelogPage
  • AboutPage
  • How it's builtPage
Back

CVE-2023-53778

accel/qaic: Clean up integer overflow checking in map_user_pages()

High7.8EPSS 0.14%
Published
Updated
Reserved
Assigned by
Linux

Description

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.

Scores

CVSS scores of CVE-2023-53778, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
NVDNVD · Deferred3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS (exploitation in 30 days)
0.14% · top 96% of all CVEs (6 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

  • Linux · Linux

    • affected 129776ac2e38231fa9c02ce20e116c99de291666 – < d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3
    • affected 129776ac2e38231fa9c02ce20e116c99de291666 – < 96d3c1cadedb6ae2e8965e19cd12caa244afbd9c
  • Linux · Linux

    • affected 6.4
    • unaffected < 6.4
    • unaffected 6.4.12 – ≤ 6.4.*
    • unaffected 6.5 – ≤ *

References (2)

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2023-53778 badge
[![CVE-2023-53778](https://trackcve.app/badge/CVE-2023-53778.svg)](https://trackcve.app/cve/CVE-2023-53778)

Record last updated .