CVE-2026-53151

What it actually does

This flaw affects the Linux kernel AF_RXRPC implementation when parsing ACK packets that contain selective acknowledgement (SACK) data. The vulnerable code assumes the received socket buffer is safely condensed into a flat buffer before accessing the SACK table, but that operation can silently fail, especially with deliberately fragmented UDP packets. As a result, the kernel may read or process packet data incorrectly while handling RXRPC ACKs, potentially leading to kernel memory access faults, incorrect protocol state handling, or denial of service through a kernel crash. The issue is in kernel packet parsing logic and does not require application-level parsing once AF_RXRPC traffic reaches the vulnerable code path.

Why it matters to the business

Systems using the Linux kernel RXRPC/AFS networking stack could be disrupted by specially crafted network traffic, causing service instability or host crashes. The risk is lower than widely exploited internet-facing remote-code-execution issues because public exploit maturity is currently reported as none, EPSS is low, and it is not listed in CISA KEV; however, kernel-level network parsing bugs still deserve timely remediation on systems that enable RXRPC, AFS, or related UDP services because exploitation can affect availability of the whole host.

How an attack unfolds

An attacker first identifies a system that accepts or processes AF_RXRPC traffic, commonly associated with AFS/RXRPC usage over UDP. The attacker then sends malformed or deliberately fragmented UDP packets that are structured as RXRPC ACKs with SACK table content. When the vulnerable kernel receives the packet, the AF_RXRPC ACK parser attempts to access the SACK table after assuming the socket buffer has been successfully flattened. If the buffer remains fragmented or is otherwise not laid out as expected, the parser may access the wrong memory region or fail while parsing. The most likely practical outcome is a kernel fault or crash, creating a denial-of-service condition; evidence of successful exploitation would typically appear as kernel oops, panic, or crash logs referencing RXRPC ACK parsing functions.

How to fix it

Upgrade to a Linux kernel version that includes the AF_RXRPC ACK parser fix for this issue. Use the fixed kernel packages supplied by the operating system or appliance vendor, since fixed versions vary by distribution and kernel branch. If immediate patching is not possible, reduce exposure by disabling or unloading unused RXRPC/AFS functionality, disabling kernel AFS clients or services where not required, and restricting RXRPC/AFS-related UDP traffic to trusted peers only. Network controls should also block unexpected fragmented UDP traffic to RXRPC/AFS service ports where operationally feasible. Because this is a kernel-space flaw, application-layer workarounds are generally insufficient if the vulnerable protocol path remains reachable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for this vulnerability, not merely that an updated package is installed but inactive. Validate the active kernel with standard system commands such as checking the running kernel release after reboot and comparing it with the distribution advisory. Confirm whether RXRPC support is present or loaded by checking kernel configuration and loaded modules, for example CONFIG_AF_RXRPC and the rxrpc module. Review firewall and network policy to ensure untrusted UDP RXRPC/AFS traffic is blocked if the protocol is not required. Where safe, use a non-production test system to confirm that fragmented RXRPC ACK traffic no longer produces kernel warnings, oopses, or crashes.

Typical attack path

1. Identify hosts that expose or use RXRPC/AFS-related UDP traffic.
2. Confirm that the target is running a Linux kernel build with the vulnerable AF_RXRPC ACK parser.
3. Craft RXRPC ACK packets containing SACK data, with packet layout designed to exercise fragmented socket-buffer handling.
4. Send the crafted packets, often as fragmented UDP traffic, to the target RXRPC service or socket.
5. Trigger AF_RXRPC ACK parsing in the kernel.
6. Cause malformed SACK parsing, invalid buffer access, kernel fault, or service-impacting crash.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and network telemetry around unexplained host instability, reboots, or kernel panics. Focus on logs containing RXRPC function names, AF_RXRPC references, kernel oops messages, general protection faults, page faults, or panic traces that occur shortly after inbound fragmented UDP traffic. Network evidence may include unusual IP fragmentation, repeated UDP fragments to AFS/RXRPC-related ports, malformed RXRPC ACK traffic, or traffic from untrusted sources to systems that should not receive RXRPC. If packet capture is available, inspect for fragmented UDP packets carrying RXRPC ACKs with SACK-related data. Because there are no widely established public exploit signatures for this issue, detection should combine crash telemetry, kernel stack traces, and network-fragmentation anomalies rather than relying on a single IOC.

• rxrpc_input_soft_acks
• rxrpc_input_ack
• AF_RXRPC
• net/rxrpc
• BUG: unable to handle kernel paging request
• general protection fault
• Kernel panic - not syncing
• Oops:
• Modules linked in: rxrpc
• skb_condense
• fragmented UDP
• UDP dst port 7000
• UDP dst port 7001
• UDP dst port 7002
• UDP dst port 7003
• UDP dst port 7004
• UDP dst port 7005
• UDP dst port 7006
• UDP dst port 7007
• UDP dst port 7008
• UDP dst port 7009

What your security team should do

• Prioritize kernel updates on systems that use AFS, kAFS, RXRPC, or expose UDP services associated with RXRPC/AFS.
• Inventory systems with AF_RXRPC support enabled or the rxrpc module loaded, then separate internet-exposed systems from internal-only systems for patch prioritization.
• If RXRPC/AFS is not required, disable the functionality or prevent the relevant module from loading.
• Restrict UDP RXRPC/AFS traffic to trusted sources and block unexpected fragmented UDP traffic where this will not disrupt legitimate operations.
• Monitor kernel logs and crash telemetry for RXRPC-related faults, especially after fragmented UDP traffic or unexplained host reboots.
• Treat unexplained kernel crashes referencing rxrpc_input_soft_acks or rxrpc_input_ack as potentially suspicious until packet-level and crash evidence is reviewed.