Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-46064ibmasm: fix heap over-read in ibmasm_send_i2o_message()

Description

In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.

Timeline

  1. ID reserved

    By Linux

  2. · 14 days later

    Published

  3. · 5 months later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-46064, by who scored it
Scored byCVSSScoreVector
NVDNVD · Undergoing Analysis3.1High7.1CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
EPSS (exploitation in 30 days)
0.14% · top 96% of all CVEs (13 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.1.

Affected products

  • Linux · Linux

    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < ca1c857e2bb74a9fc0606128334f85316d57067b
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < b870f652877bfbe321bd0f4096fc37a93296f7b6
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < ce57fa439bd1b5d664f334a0c3e3f0e42abb0153
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < fd19eb1c75047a4ed4e855f56cafd704dc3914e0
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < fe31722b0194ff76bf8b461e8bf97a2081147787
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < c1c2417c60dbdca5ebb00462f21ee71c2d7f7083
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < 9e8f6c9d4ecddda2f28baa1678340286cff3969c
    • affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 – < 9aad71144fa3682cca3837a06c8623016790e7ec
  • Linux · Linux

    • affected 2.6.12
    • unaffected < 2.6.12
    • unaffected 5.10.258 – ≤ 5.10.*
    • unaffected 5.15.209 – ≤ 5.15.*
    • unaffected 6.1.175 – ≤ 6.1.*
    • unaffected 6.6.140 – ≤ 6.6.*
    • unaffected 6.12.86 – ≤ 6.12.*
    • unaffected 6.18.27 – ≤ 6.18.*
    • unaffected 7.0.4 – ≤ 7.0.*
    • unaffected 7.1 – ≤ *

References

References9

Sources

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

Badge for a README or a ticket

CVE-2026-46064 badge
[![CVE-2026-46064](https://cveledger.app/badge/CVE-2026-46064.svg)](https://cveledger.app/cve/CVE-2026-46064)

Record last updated .