Linux Kernel CVE-2024-56647 ICMP Relookup Bug Triggers ip_rt_bug

A small but consequential Linux kernel networking bug — tracked as CVE‑2024‑56647 — was disclosed and fixed in late December 2024; it can cause the kernel to hit an ip_rt_bug during certain ICMP error handling paths when IPsec (XFRM) is enabled, producing kernel warnings or OOPSes and risking availability of affected hosts.

Background​

Modern Linux networking ties together multiple subsystems: routing, neighbor/ARP handling, ICMP error reporting, and optional IPsec XFRM transformations. That integration is powerful but also sensitive to subtle state changes when the stack performs route re‑lookups for locally generated packets while XFRM is active.
CVE‑2024‑56647 arises when an ICMP error path performs an icmp host relookup (route re‑validation) under XFRM, and the resulting route state ends up inconsistent for an ICMP DEST_UNREACH reply. In the worst-observed case the kernel hits an internal sanity check handler — the ip_rt_bug trace — producing a kernel WARNING/OOPS and an availability impact. The vulnerability and the minimal repro steps were published as part of the coordinated vendor advisories and upstream kernel fixes.

Technical overview​

What the bug looks like in the kernel​

When the kernel generates or handles ICMP errors for locally generated packets, it sometimes needs to perform a route relookup to select an appropriate input route for the ICMP reply. Under certain XFRM (IPsec) relookup conditions, the code path may incorrectly set the dst->out pointer on the newly chosen route to a sentinel value that later triggers the ip_rt_bug assertion during an skb transmit path. The observable symptom is a kernel WARNING showing ip_rt_bug originating from net/ipv4/route.c followed by a stack trace that includes icmp_send and ip_send_skb. Multiple vendor trackers reproduce the call trace in advisories. A representative excerpt of the call-stack reported in advisories shows the kernel backtrace flowing from ip_send_skb into icmp_send and then into the IPv4 link-failure/ARP neighbor handling code — the exact path where route state and neighbor invalidation interact. The bug can be reproduced in a controlled environment using a scripted sequence that configures an XFRM policy, creates a veth pair, assigns an address and issues a ping that triggers the faulty relookup. Advisories include the short reproduction recipe that many admins and maintainers used to validate the fix.

Root cause in plain language​

• The kernel performs an icmp relookup for certain ICMP replies.
• If XFRM is enabled and the packet is locally generated, the relookup can create an input route object whose output route pointer (dst->out) is set to a special marker (ip_rt_bug) in some cases.
• Downstream transmit code expects coherent route state; encountering the ip_rt_bug marker triggers an internal assertion which manifests as a WARNING or OOPS (availability failure).
• The fix is pragmatic: skip the icmp relookup for locally generated packets, avoiding the inconsistent state on loopback-like output paths where XFRM rechecks are unnecessary.

Which code was changed upstream​

Upstream kernel maintainers applied a small, targeted change that avoids performing the XFRM relookup for ICMP handling of locally generated packets on the loopback/output path. The kernel stable commits fixing the bug were merged into the stable trees and referenced by vendor advisories; NVD and distribution trackers point at the kernel.org patch entries for the official diffs. Because the change is narrowly scoped and defensive, it is a minimal-risk patch from a regression perspective.

---

Affected systems and vendor response​

Severity and exploitability​

• CVSS (3.x) scoring and vendor trackers place the issue at Medium (around 5.5) with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H — that is, local attack vector, low complexity, low privilege required, and primarily an availability impact.
• Exploitability: the bug is local rather than remotely exploitable in the normal sense. To trigger it an attacker or buggy process must be able to induce the conditions that create the problematic icmp relookup (for example, by running a process that causes locally-generated ICMP error replies while XFRM policies are in place). In multi‑tenant or shared environments this “local” requirement can translate into a real risk — a container tenant, CI job or VM tenant could potentially cause host instability. Public advisories and vulnerability trackers list no widespread in‑the‑wild exploitation known at disclosure; absence of observed exploitation is not a guarantee it cannot be abused in targeted scenarios.

What vendors and distros published​

Major Linux distributors and cloud vendors incorporated the upstream fix into their packages and advisories:

• Ubuntu assigned Medium priority, published the vulnerability and listed fixed package mappings for its kernel packages.
• Debian tracked the CVE and published affected/fixed package mappings (fixed in unstable/trixie kernel builds).
• Red Hat / Oracle / Amazon Linux (ALAS) also published advisories or included the CVE in their kernel errata and backport streams.

If you run distribution kernels, the practical route to remediation is to apply the vendor-supplied kernel packages that explicitly list the CVE or the upstream commit hashes in the changelog.

Microsoft / Azure context​

Microsoft’s vulnerability visibility work and public attestation practice means Microsoft may list Azure Linux or certain Microsoft-managed Linux artifacts where inventory shows the vulnerable component is present; treat such entries as product‑specific attestations rather than universal guarantees about all Microsoft‑shipped artifacts. Administrators running Linux on Azure, WSL, or other Microsoft surfaces should check the vendor‑specific VEX/CSAF entries and kernel package mappings for confirmation on each artifact. The community discussion and vendor-cross checks emphasize that product-level attestations are scoped to the named artifact.

---

Practical impact and risk scenarios​

Realistic attack scenarios​

• Multi‑tenant cloud host: an untrusted tenant or VM could, in principle, cause locally-generated ICMP reactions or otherwise exercise networking code paths that trigger the relookup, producing repeated kernel warnings or even a host panic. That can lead to service disruption or VM restarts.
• Shared development servers: CI/build agents or containerized workloads with networking privileges may reproduce the bug if XFRM policies and the specific sequence that causes the relookup are present.
• Embedded/network appliances: devices that compile kernels with XFRM enabled and that perform aggressive ARP/neigh/ICMP handling could be exposed — especially if vendors have not backported the kernel stable fix.

What this does NOT do (important limits)​

• This is not a remote code execution or direct privilege‑escalation CVE in the standard vendor writeups. The immediate and confirmed impact is availability (kernel warnings/OOPS) rather than confidentiality or integrity compromise. Vendor advisories and NVD entries uniformly focus on DoS-style outcomes.
• There were no authoritative public proofs-of-concept for remote exploitation at the time of publication; that said, kernel bugs are sometimes used as components in complex multi‑stage attacks, so conservative patching is still the right posture.

---

Detection, verification, and reproduction​

Indicators to watch for​

• Kernel messages that include ip_rt_bug or a stack trace naming ip_send_skb and __icmp_send. Grep for these strings in dmesg or your central log collection pipeline.
• Repeated WARN/OOPS entries in host kernel logs correlated with ICMP/neighbor/ARP activity or with XFRM policy installs/changes.

Suggested quick checks:

• dmesg | grep -E 'ip_rt_bug|__icmp_send|ip_send_skb'
• journalctl -k | grep -i icmp

These are practical hunting signals — collect full dmesg when you see a kernel WARNING and preserve vmcores for post‑mortem analysis where feasible.

Repro recipe (test lab only)​

Advisories include a concise reproduction recipe; a safe paraphrase:

• Add a permissive XFRM policy (example: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 0 ptype main flag localok icmp).
• Create a veth pair and assign an address to one side.
• On the other side, issue a ping to that address once (ping -c 1).
• Observe the kernel dmesg for the ip_rt_bug/OOPS triggering in the ICMP/ARP/neigh code paths.

Only run these steps in an isolated lab — do not experiment on production hosts. Vendors published the same procedure in their advisories to help maintainers verify fixes.

---

Mitigation and remediation guidance​

Definitive remediation​

• Apply vendor kernel updates. The only reliable permanent fix is to install the distribution- or vendor-provided kernel package that includes the upstream stable commits which implement the icmp relookup skip. After installing the kernel update, schedule and perform a reboot to bring the patched kernel into service. Vendors (Ubuntu, Debian, Red Hat, Oracle, Amazon) have mapped the fix into their packages — follow the vendor advisory for your distro and kernel series.
• For cloud-managed images (Azure, AWS, Google), use the vendor’s patched image updates or kernel packages for guest VMs and confirm the fix is present before rolling to production. Managed cloud images and marketplace artifacts can differ in kernel config and must be checked individually.

Short-term mitigations (if you cannot patch immediately)​

• Disable XFRM processing on loopback interfaces via sysctl: set net.ipv4.conf.lo.disable_xfrm = 1 where appropriate. This instructs the stack to avoid XFRM revalidation on loopback output, reducing the chance of this specific relookup scenario. Use extreme caution: changing XFRM behavior can alter IPsec semantics for local routing and must be risk-assessed.
• Restrict untrusted local code or container privileges that can manipulate networking stack behavior. In multi‑tenant hosts, limit which containers/pods/VMs may install XFRM policies or perform network manipulations.
• Monitor kernel logs closely and, where necessary, schedule maintenance windows to apply kernel updates promptly rather than relying on long-term sysctl workarounds.

Prioritized remediation checklist (operational playbook)​

• Inventory: run uname -a; identify hosts with kernels in the affected series and those with CONFIG_XFRM or related IPsec features enabled.
• Consult your distribution advisory and match the package changelog to the upstream commit IDs referenced in advisories. Do not assume kernel version numbers alone — verify that the backport or stable package explicitly includes the fix.
• Test: stage the vendor kernel update in a pilot group that mirrors production network workloads. Validate that ICMP/neighbor/ARP behaviors are intact.
• Rollout: schedule staged reboots and monitor for post‑patch regressions.
• Post‑patch monitoring: watch for the previously observed ip_rt_bug traces and confirm hosts remain stable.

---

Why this fix matters — strengths and remaining risks​

Strengths​

• The upstream patch is small and surgical, addressing the precise relookup decision without wholesale rewrites of routing or XFRM subsystems. That conservative approach minimizes regression risk while removing the inconsistent state that caused the ip_rt_bug. Vendor trackers and the kernel stable branches incorporated the patch quickly, and distribution backports were published in a timely manner.
• The vulnerability’s scope (local/availability) gives defenders clear mitigation and remediation paths: restrict local network/change privileges and install patched kernels.

Remaining risks and caveats​

• Local DoS primitives are often undervalued in multi‑tenant/cloud settings: an attacker able to run code as an unprivileged tenant can sometimes achieve significant operational impact. The CVE’s local-vector classification therefore does not equal low operational priority. Hardened multi‑tenant hosts should treat this as a high-priority availability fix.
• Distribution lag: vendors backport fixes on different cadences. Embedded devices or vendor kernels with long patch cycles may remain exposed long after upstream fixes arrive. Inventory and vendor engagement remain essential.
• Theoretical chaining: while there is no public evidence that this specific flaw leads to escalations beyond DoS, the kernel is a complex attack surface; defenders should avoid complacency and patch promptly.

---

Detection and incident response playbook​

• If you see ip_rt_bug or kernel OOPS referencing __icmp_send / ip_send_skb in logs, isolate the affected host and preserve dmesg/journal and any vmcore.
• Correlate the event to recent XFRM policy installs, neighbor invalidations, or container/VM network operations.
• If patching is possible immediately, schedule a rapid maintenance window to deploy vendor kernel updates and reboot. If not, consider the short-term sysctl mitigation (net.ipv4.conf.lo.disable_xfrm = 1) while you plan updates. Remember to document the temporary change and roll it back after patching.

---

Conclusion​

CVE‑2024‑56647 is a narrowly scoped but practical kernel bug that produces a kernel ip_rt_bug when ICMP host relookup runs concurrently with XFRM (IPsec) revalidation. The impact is availability — kernel warnings, OOPSes, and potential host disruption — and the fix is straightforward: skip the unnecessary relookup for locally generated ICMP replies. Upstream maintainers implemented a small, low‑risk patch and major distributions incorporated the fix into kernel packages; administrators should prioritize installing vendor-supplied kernel updates and reboots as the definitive remediation. For environments that cannot patch immediately, short‑term mitigations exist but must be applied with care and reverted once the proper kernel update is installed. Vigilant log monitoring for ip_rt_bug traces and a fast, inventory‑driven patching workflow remain the best defense.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center