CVE-2026-46081 (GCVE-0-2026-46081)
Vulnerability from cvelistv5
Published
2026-05-27 12:58
Modified
2026-08-05 12:29
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: crypto: acomp - fix wrong pointer stored by acomp_save_req() acomp_save_req() stores &req->chain in req->base.data. When acomp_reqchain_done() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acomp_req. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption. The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomp_request_set_src_dma()). This combination causes crypto_acomp_compress() to enter the acomp_do_req_chain() path, which sets acomp_reqchain_done() as the completion callback via acomp_save_req(). With KASAN enabled, this manifests as a general protection fault in acomp_reqchain_done(): general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acomp_reqchain_done+0x15b/0x4e0 Call Trace: <IRQ> qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 </IRQ> Fix this by storing the request itself in req->base.data instead of &req->chain, so that acomp_reqchain_done() receives the correct pointer. Simplify acomp_restore_req() accordingly to access req->chain directly.
References
Impacted products
Vendor Product Version
Linux Linux Version: 64929fe8c0a43508eee952cf57903a61c52601e7
Version: 64929fe8c0a43508eee952cf57903a61c52601e7
Version: 64929fe8c0a43508eee952cf57903a61c52601e7
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "crypto/acompress.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "343a5bf68a8ff9affcf2b70677ea4cf40c195ee4",
              "status": "affected",
              "version": "64929fe8c0a43508eee952cf57903a61c52601e7",
              "versionType": "git"
            },
            {
              "lessThan": "1a2785e5985627f2265ba7775949601a29ba0d1e",
              "status": "affected",
              "version": "64929fe8c0a43508eee952cf57903a61c52601e7",
              "versionType": "git"
            },
            {
              "lessThan": "d7e20b9bd6c990773cf0c09e2642250b8a70263d",
              "status": "affected",
              "version": "64929fe8c0a43508eee952cf57903a61c52601e7",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "crypto/acompress.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.16"
            },
            {
              "lessThan": "6.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.27",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.27",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.4",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: acomp - fix wrong pointer stored by acomp_save_req()\n\nacomp_save_req() stores \u0026req-\u003echain in req-\u003ebase.data. When\nacomp_reqchain_done() is invoked on asynchronous completion, it receives\n\u0026req-\u003echain as the data argument but casts it directly to struct\nacomp_req. Since data points to the chain member, all subsequent field\naccesses are at a wrong offset, resulting in memory corruption.\n\nThe issue occurs when an asynchronous hardware implementation, such as\nthe QAT driver, completes a request that uses the DMA virtual address\ninterface (e.g. acomp_request_set_src_dma()). This combination causes\ncrypto_acomp_compress() to enter the acomp_do_req_chain() path, which\nsets acomp_reqchain_done() as the completion callback via\nacomp_save_req().\n\nWith KASAN enabled, this manifests as a general protection fault in\nacomp_reqchain_done():\n\n  general protection fault, probably for non-canonical address 0xe000040000000000\n  KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]\n  RIP: 0010:acomp_reqchain_done+0x15b/0x4e0\n  Call Trace:\n   \u003cIRQ\u003e\n   qat_comp_alg_callback+0x5d/0xa0 [intel_qat]\n   adf_ring_response_handler+0x376/0x8b0 [intel_qat]\n   adf_response_handler+0x60/0x170 [intel_qat]\n   tasklet_action_common+0x223/0x820\n   handle_softirqs+0x1ab/0x640\n   \u003c/IRQ\u003e\n\nFix this by storing the request itself in req-\u003ebase.data instead of\n\u0026req-\u003echain, so that acomp_reqchain_done() receives the correct pointer.\nSimplify acomp_restore_req() accordingly to access req-\u003echain directly."
        }
      ],
      "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 only affected callers reaching the buggy chain path use the virtual-DMA interface from local contexts (UBIFS filesystem I/O); all network-facing acomp users (IPComp) use scatterlists and skip the vulnerable path, so there is no remote vector.\nAC:L - Within an affected configuration (async hardware accelerator bound to the compressor), ordinary compress/decompress operations deterministically take the async completion path and corrupt memory; there is no race to win or attacker-uncontrolled state required to trigger it.\nPR:L - Triggering requires only local read/write access to a UBIFS-backed file, which an ordinary unprivileged user has on systems where UBIFS holds user-accessible data; no elevated capability is needed.\nUI:N - The attacker triggers (de)compression through their own file operations; no action by another user is required.\nS:U - The corruption is confined to kernel memory within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Casting the chain pointer to a request struct causes out-of-bounds reads and dereferences at wrong offsets, and this memory corruption can be leveraged for kernel information disclosure.\nI:H - The bug performs out-of-bounds writes (e.g. via acomp_request_set_src_dma at the wrong offset) and calls a function pointer fetched from a wrong offset, providing a control-flow-hijack and arbitrary-write primitive.\nA:H - The wrong-offset dereference produces a confirmed general protection fault / kernel panic in IRQ/tasklet context, crashing the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:29:32.090Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/343a5bf68a8ff9affcf2b70677ea4cf40c195ee4"
        },
        {
          "url": "https://git.kernel.org/stable/c/1a2785e5985627f2265ba7775949601a29ba0d1e"
        },
        {
          "url": "https://git.kernel.org/stable/c/d7e20b9bd6c990773cf0c09e2642250b8a70263d"
        }
      ],
      "title": "crypto: acomp - fix wrong pointer stored by acomp_save_req()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-46081",
    "datePublished": "2026-05-27T12:58:19.498Z",
    "dateReserved": "2026-05-13T15:03:33.096Z",
    "dateUpdated": "2026-08-05T12:29:32.090Z",
    "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.