CVE-2026-46000: rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
The security operations that verify the RESPONSE packets decrypt bits of it
in place - however, the sk_buff may be shared with a packet sniffer, which
would lead to the sniffer seeing an apparently corrupt packet (actually
decrypted).
Fix this by handing a copy of the packet off to the specific security
handler if the packet was cloned.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects rxrpc packet handling. A shared network packet buffer can be modified during RESPONSE packet verification, causing another observer such as a packet sniffer to see altered packet contents. The sources describe data corruption/visibility behavior, not remote code execution or privilege escalation.
Executive priority
Treat this as a kernel maintenance item unless local rxrpc use makes it operationally important. There is no sourced evidence of exploitation or high-impact compromise, but affected kernels should move to vendor-fixed releases through normal patch governance.
Technical view
rxrpc connection-level RESPONSE packet verification decrypts parts of the packet in place. When the sk_buff is cloned, that mutation can affect a shared copy. The upstream fix copies the packet before handing it to the security handler when cloning is present.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions where rxrpc code is present and relevant traffic or packet capture paths are used. The bundle does not identify affected distributions, default configurations, or specific applications.
Exploitation context
No cited source reports active exploitation, and the CVE is not marked KEV. The public description frames this as incorrect shared-buffer handling with packet sniffer side effects, not a documented attacker workflow.
Researcher notes
The key condition is cloned sk_buff handling during rxrpc RESPONSE security verification. Public sources provide the fix concept and stable commit references, but no CVSS, CWE, exploitability assessment, affected distro matrix, or operational workaround.
Mitigation direction
Update to a Linux kernel containing the referenced stable fixes.
Check your Linux distribution advisory for the packaged fixed kernel version.
Prioritize systems known to use rxrpc or rxrpc-related workloads.
Review packet capture or monitoring dependencies around rxrpc traffic.
If patch timing is unclear, follow vendor guidance rather than applying assumptions.
Validation and detection
Inventory Linux kernel versions against vendor fixed-version guidance.
Confirm whether rxrpc support is built, loaded, or used on relevant systems.
Verify the deployed kernel includes the applicable stable fix commit.
Regression test rxrpc-dependent workloads after kernel update.
Review monitoring for unexpected rxrpc RESPONSE packet corruption reports.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46000 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 12:55 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.