RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.258, 5.15.209, 6.1.175, 6.12.86, 6.18.27, 6.6.140, 7.0.4
- CVEs
- CVE-2026-46043
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 21:25 UTC · Revision 1
Source evidence
RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv
core-osv · Original sourcePublished 27 May 2026, 12:56 UTC
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.
osv:CVE-2026-46043
Kernel
Fixed versions: 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4
Complete source record
{
"id": "764f503601f6426c8920c90520688f7b2ba2e2e7b732f77da36cc91b6e3d9781",
"url": "https://osv.dev/vulnerability/CVE-2026-46043",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"summary": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.",
"evidence": "osv:CVE-2026-46043",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.258",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.209",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.175",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.140",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.86",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.27",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "critical",
"structured": {
"id": "CVE-2026-46043",
"aliases": [
"CVE-2026-46043"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "8700e3e7c4857d28ebaa824509934556da0b3e76"
},
{
"fixed": "c4376c672c3648d5bdc31dfffc329d07164f93c4"
},
{
"fixed": "5fedefec757192dcaad29a664ac332c7601be144"
},
{
"fixed": "2c0d71ef12f46c57d37bc571f3f2797db7eb50cc"
},
{
"fixed": "2fd4f8b749309a61c3f3f88ee8891d94f79e1240"
},
{
"fixed": "f83519a4c122c9c7a850a2197648a9ff4c67c520"
},
{
"fixed": "9b924f3a26b21330a837cfe72e819b6393bbeeaa"
},
{
"fixed": "e8ee0e792d475b1067c199ef0af1b6221fa6f43d"
},
{
"fixed": "7244491dab347f648e661da96dc0febadd9daec3"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-46043.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.8.0"
},
{
"fixed": "5.10.258"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.209"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.175"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.140"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.86"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.27"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.0.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-46043.json"
}
}
],
"modified": "2026-10-28T02:30:39.624117065Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/2c0d71ef12f46c57d37bc571f3f2797db7eb50cc",
"https://git.kernel.org/stable/c/2fd4f8b749309a61c3f3f88ee8891d94f79e1240",
"https://git.kernel.org/stable/c/5fedefec757192dcaad29a664ac332c7601be144",
"https://git.kernel.org/stable/c/7244491dab347f648e661da96dc0febadd9daec3",
"https://git.kernel.org/stable/c/9b924f3a26b21330a837cfe72e819b6393bbeeaa",
"https://git.kernel.org/stable/c/c4376c672c3648d5bdc31dfffc329d07164f93c4",
"https://git.kernel.org/stable/c/e8ee0e792d475b1067c199ef0af1b6221fa6f43d",
"https://git.kernel.org/stable/c/f83519a4c122c9c7a850a2197648a9ff4c67c520",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46043.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-46043",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46043.json"
}
},
"related_cves": [
{
"value": "CVE-2026-46043",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 507241,
"published_at": "2026-05-27T12:56:57.987+00:00"
}