GHSA-PV35-9GQP-7Q2C

Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-05-28 12:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads

atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt):

value = *(u64 *)payload_addr(pkt);

check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC).

IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path.

Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-46114"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T10:16:26Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads\n\natomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c\nunconditionally dereferences 8 bytes at payload_addr(pkt):\n\n    value = *(u64 *)payload_addr(pkt);\n\ncheck_rkey() previously accepted an ATOMIC_WRITE request with pktlen ==\nresid == 0 because the length validation only compared pktlen against\nresid. A remote initiator that sets the RETH length to 0 therefore reaches\natomic_write_reply() with a zero-byte logical payload, and the responder\nreads sizeof(u64) bytes from past the logical end of the packet into\nskb-\u003ehead tailroom, then writes those 8 bytes into the attacker\u0027s MR via\nrxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel\ntailroom per probe (the other 4 bytes are the packet\u0027s own trailing ICRC).\n\nIBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is\nprotocol-invalid. Hoist a strict length check into check_rkey() so the\nresponder never reaches the unchecked dereference, and keep the existing\nWRITE-family length logic for the normal RDMA WRITE path.\n\nReproduced on mainline with an unmodified rxe driver: a sustained\nzero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer\nbytes into the attacker\u0027s MR, including recognisable kernel strings and\npartial kernel-direct-map pointer words.  With this patch applied the\nresponder rejects the PDU and the MR stays all-zero.",
  "id": "GHSA-pv35-9gqp-7q2c",
  "modified": "2026-05-28T12:30:29Z",
  "published": "2026-05-28T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46114"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/105bf79a23b85cf3a761d18a4f3e10ce88526bc1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1114c87aa6f195cf07da55a27b2122ae26557b26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/539cabb7b2d8ba70f55bba91db55faef11c2a6d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ec1ed4747f5f99f8b797bb438c5efd36079fad5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d415fce3fcde6d7aeea6c25362a395b905811452"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.