CVE-2026-46000

What it actually does

This flaw affects Linux kernel rxrpc connection-level packet handling. When rxrpc RESPONSE packets are processed, the security verification path decrypts portions of the packet in place. If the underlying sk_buff is cloned or shared with a packet-capture consumer, such as a sniffer using packet sockets, the shared buffer can be modified unexpectedly. The result is that observers of the shared packet may receive corrupted or partially decrypted packet contents. The assigned impact is availability-focused: a local low-privileged user can potentially trigger conditions that disrupt packet inspection, tracing, or rxrpc-related monitoring accuracy. There is no indication from the provided data of remote code execution, privilege escalation, or direct data exfiltration.

Why it matters to the business

Organizations using Linux systems with rxrpc enabled or present may experience unreliable packet capture, traffic analysis, or monitoring around rxrpc traffic. This can reduce confidence in diagnostics, incident response evidence, and network observability on affected hosts. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported exploit maturity, so urgency is moderate to low unless the environment relies heavily on rxrpc, AFS, packet capture, or forensic monitoring on Linux endpoints.

How an attack unfolds

An attacker needs local access with enough privileges to generate or interact with rxrpc traffic and to place the system in a state where rxrpc RESPONSE packets are also observed by a packet-capture path. The attacker causes rxrpc RESPONSE packets to be processed while the associated sk_buff is cloned or shared. During security verification, the rxrpc code decrypts parts of the packet in place instead of operating on an unshared copy. Because the buffer is shared, the sniffer or packet consumer may see altered packet contents. The practical exploitation outcome is disruption or corruption of captured packet data, which can interfere with troubleshooting, security monitoring, or evidence collection. The published fix changes the handling so cloned packets are copied before security-specific processing modifies them.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the rxrpc fix for connection-level RESPONSE packet handling. No exact fixed package versions were provided in the input, so use the relevant distribution advisory for the deployed kernel stream and reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by disabling or avoiding rxrpc-dependent services where operationally feasible, unloading unused rxrpc-related kernel modules if supported and safe, and limiting local shell access to trusted users. If packet capture integrity is operationally important, prioritize patching systems that perform network monitoring, diagnostics, AFS/rxrpc operations, or forensic packet collection.

How to confirm the fix worked

Confirm the system is running a kernel build that includes the rxrpc unshare/copy fix for cloned RESPONSE packets. Validate through the operating system vendor advisory, package changelog, kernel version mapping, or source commit history. After patching, reboot and verify the active kernel is the updated kernel, not only that the package is installed. Functional validation can include capturing rxrpc traffic before and after patching and confirming packet captures no longer show unexpected corruption associated with rxrpc RESPONSE handling. Also verify that any temporary mitigations, such as disabled rxrpc services or unloaded modules, remain in the intended state until patching is complete.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel.
2. Identify whether rxrpc support is available or in use, such as through AFS/rxrpc-related components or kernel module availability.
3. Generate or trigger rxrpc connection-level traffic that includes RESPONSE packets.
4. Run or induce packet capture or packet-socket observation so the packet buffer may be cloned or shared.
5. Cause the rxrpc security verification path to process the shared RESPONSE packet.
6. Leverage the in-place modification behavior to cause packet captures or monitoring output to show corrupted packet data.

How to detect it

There are no strong public indicators of active exploitation from the provided data, and exploitation is likely to look like local rxrpc activity combined with packet capture rather than a distinctive malware pattern. To assess possible prior exploitation, review audit logs, shell history, process execution telemetry, and EDR data for local users running packet-capture tools such as tcpdump, dumpcap, tshark, Wireshark, or custom AF_PACKET collectors at the same time as rxrpc or AFS activity. Examine kernel logs for rxrpc-related warnings, packet parsing errors, or unusual diagnostic output. Review packet-capture archives for rxrpc RESPONSE packets that appear malformed, unexpectedly partially decrypted, or inconsistent between simultaneous capture points. Because packet corruption can have benign diagnostic causes, correlate any findings with local user activity, unexpected capture processes, and rxrpc service use before treating them as confirmed exploitation.

• rxrpc
• AF_RXRPC
• af_rxrpc
• kafs
• openafs
• tcpdump
• dumpcap
• tshark
• wireshark
• AF_PACKET
• packet socket
• rxrpc:
• RESPONSE packet
• malformed rxrpc
• corrupt rxrpc

What your security team should do

• Inventory Linux hosts and prioritize systems where rxrpc, AFS, packet capture, network monitoring, or forensic collection is used.
• Apply vendor kernel updates that include the rxrpc RESPONSE packet handling fix, then reboot to activate the patched kernel.
• Treat this as lower urgency than KEV or weaponized remote vulnerabilities, but do not ignore systems that rely on packet capture integrity.
• Restrict local access to Linux systems where kernel patching is delayed, since exploitation requires local privileges according to the provided CVSS vector.
• Review packet-capture tooling and monitoring workflows on affected systems for unexplained rxrpc packet corruption during the exposure window.
• Track distribution advisories for exact fixed kernel versions because no fixed versions were provided in the input.