7.8

CVE-2023-53778: linux

CVSS: 7.8v3.1HighDeferred
AliasesUBUNTU-CVE-2023-53778DEBIAN-CVE-2023-53778
Published 09-12-2025Last modified 05-08-2026

Vulnerability summary

CVE-2023-53778 is a high (CVSS 7.8) vulnerability in linux. EPSS estimates a 0.14% chance of exploitation in the next 30 days, higher than 3.2% of scored vulnerabilities.

Overall risk
31/100
0100
Medium · default modelHow is this calculated?
CVSS score
7.8/10
010
High · v3.1 (CVE.org)
EPSS score
0.14%
0%100%
Low · 0.00 pp in 30 days
KEVNot listedIn no KEV catalog
RansomwareNone recordedNo known use recorded
Public exploits0No public exploits recorded

Advisory lineage

Upstream 0 · Downstream 8 · Related 8

Timeline

  1. 09-12-2025
    PublishedVulnerability first disclosed.
  2. 05-08-2026
    Last modifiedVulnerability information updated.

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.

CVSS metrics

4 scores · 4 sources · 1 version

EPSS trend

Probability

0.14%

Chance of exploitation in the next 30 days

Percentile

3%

Versus all other CVEs

30-day change

0.00 pp

From 0.14% on 21-09-2026

21-09-202621-10-2026
EPSS score
0.14%

Known exploited

Compare KEV catalogs

Not in any of the 3 tracked catalogs.

Public exploits

0 found

No public exploits indexed.

Weaknesses

CWE · root cause

No weakness data has been published for this record.

Affected systems

Ubuntu85 products
  • linux-allwinner-5.19All versions (No fix recorded)
  • linux-aws-5.0All versions (No fix recorded)
  • linux-aws-5.11All versions (No fix recorded)
  • linux-aws-5.13All versions (No fix recorded)
  • linux-aws-5.19All versions (No fix recorded)
Debian1 product
  • linux< 6.4.13-1
Linux1 product
  • linux≥ 129776ac2e38231fa9c02ce20e116c99de291666, < d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3 | ≥ 129776ac2e38231fa9c02ce20e116c99de291666, < 96d3c1cadedb6ae2e8965e19cd12caa244afbd9c | 6.4

3 vendors · 87 products

References

6 links