CVE-2026-46037 is a newly published Linux kernel flaw disclosed by kernel.org and NVD on May 27, 2026, affecting IPv4 ICMP handling where extended echo replies could drive an out-of-range lookup in the kernel’s
The vulnerability sits in IPv4 ICMP handling, the part of the kernel responsible for the Internet Control Message Protocol messages that underpin diagnostics and error signaling. ICMP is best known through
The specific issue concerns extended echo replies. These use
That sounds like a narrow bounds-checking patch because it is one. Yet narrow bounds-checking patches in kernel packet parsers deserve more attention than their plain-language summaries usually receive. The mistake is not that ICMP is new, exotic, or unusually complex; the mistake is that a newer ICMP variant brushed against an older table assumption and the code did not draw the boundary early enough.
The important phrase in the CVE description is “before using.” Security bugs often live in that tiny ordering gap. Validate the type before indexing the table, and the code behaves as intended. Trust the type long enough to use it as an index, and the kernel may consult memory in a way the programmer did not mean.
This is increasingly normal for Linux kernel CVEs. Since kernel.org became a more direct source for CVE records, many entries have appeared as terse descriptions of resolved kernel commits rather than fully scored advisories with exploit narratives, product matrices, and vendor-specific remediation language. That is efficient for developers and often frustrating for defenders.
The danger is that teams may read “N/A” as “not important.” That is the wrong lesson. “N/A” here means the enrichment process has not supplied a score yet, not that the bug has been judged harmless.
The better triage question is not “What number did NVD assign?” It is “Do I run affected Linux kernels on machines that receive untrusted network traffic?” For most servers, routers, firewalls, NAS devices, Kubernetes nodes, hypervisors, and appliance-like systems, the answer is yes.
That second part is worth pausing on.
The result is a patch that does two things at once. It restores ordinary memory-safety discipline by refusing to index outside the valid table range. It also narrows the speculative execution window for valid indexes.
That combination is now a pattern in mature kernel code. The kernel does not just ask whether C will execute the right branch architecturally; it also asks whether the processor might transiently wander through a path that leaks information. For sysadmins, the practical conclusion is simpler: take the stable update when your distribution ships it.
Extended echo is a good example of how a benign expansion can expose a stale assumption. A table built around traditional ICMP types is not necessarily wrong. A reply path that assumes every reply type fits that table is.
This is how legacy infrastructure accumulates modern vulnerabilities. The failure is rarely a single catastrophic design decision. More often, it is the slow mismatch between old enumerations, new protocol behavior, and code paths that were never re-audited under the new assumption.
That matters because network stacks are full of such seams. IPv4 and IPv6 coexist. Tunnels wrap packets inside packets. Namespaces make one host look like many. Containers turn host kernels into shared infrastructure for mutually distrusting workloads. A bug that once would have been “just a host network oddity” can now live at the boundary between tenant and platform.
WSL itself is not the same exposure model as an internet-facing Linux server. A developer’s WSL instance is generally not the first place to panic over a remote ICMP edge case. But organizations that treat Linux as somebody else’s problem because the endpoint fleet is Windows are kidding themselves.
The more realistic enterprise map is hybrid. Windows endpoints authenticate against cloud identity, deploy code to Linux runners, administer Linux appliances, and connect to container hosts running workloads that the desktop team may never directly touch. A kernel networking fix may therefore matter to the same organization even if it does not matter to the same machine.
This is also a supply-chain problem in miniature. Many appliances do not advertise their kernel pedigree loudly. Firewalls, VPN concentrators, storage systems, monitoring probes, hyperconverged nodes, and industrial gateways may all include Linux kernels whose update cadence depends on a vendor firmware pipeline rather than the distro package manager an admin can control directly.
What we can say is that the vulnerable code path is in network-facing kernel ICMP handling. That makes it different from a local-only driver bug buried behind obscure hardware. The potentially relevant input arrives as packets, and packet-reachable kernel parsing is exactly the class of code defenders patch quickly because the margin for error is smaller.
The most conservative interpretation is that CVE-2026-46037 is a correctness and hardening fix for an out-of-range array consultation in an ICMP reply path. The more security-minded interpretation is that any out-of-range table use in the kernel network stack deserves prompt remediation before researchers or attackers turn the terse commit message into a working crash or leak primitive.
Those interpretations are not mutually exclusive. Kernel security often starts as correctness work. The exploitability of a bug may be unclear at disclosure, but the value of removing undefined or out-of-bounds behavior from packet-handling code is not.
The trap is waiting for perfect information. By the time every downstream vendor publishes a polished advisory, every scanner plugin is updated, and every dashboard has a severity score, the straightforward patch window may already have been missed. That does not mean emergency reboot every Linux machine on the planet. It does mean this CVE should enter the next kernel maintenance cycle rather than languish in a “no score, no action” queue.
Rolling fleets make this easier. Immutable images, staged node drains, live migration, and blue-green appliance pairs all exist to make kernel updates less theatrical. If a Linux kernel update still requires a heroic weekend outage, CVE-2026-46037 is less the cause of pain than a reminder that the update process itself needs modernization.
The hardest cases will be vendor-controlled devices. If the kernel is embedded in an appliance, customers may not be able to apply the upstream stable commits directly. In those cases, the right move is to ask the vendor whether their shipped kernel contains the affected ICMP code and whether the relevant stable patches have been incorporated.
This is good for speed and bad for casual comprehension. Developers can recognize the affected function family and inspect the fix. Many security teams, however, are left translating a commit-style description into business risk.
The shift places more burden on downstream distributions. Red Hat, Canonical, SUSE, Debian, cloud vendors, and appliance makers still have to convert upstream kernel fixes into the language administrators use: affected versions, fixed package names, reboot requirements, mitigations, and severity ratings. Until that happens, the upstream CVE exists in a kind of operational half-light.
That half-light is where mistakes happen. One team dismisses the bug because NVD has no CVSS score. Another treats every kernel CVE as a five-alarm fire. The mature answer sits between those extremes: understand the code path, understand the exposure, patch according to asset criticality, and avoid inventing certainty where the public record has not supplied it.
This is why the fix is conceptually clean. Do not consult the traditional table for a nontraditional type. For types that do belong to the table, use a speculation-safe index helper. Normal ICMP replies continue to behave as before.
That last point is important for administrators worried about regressions. The patch is not a redesign of ICMP handling. It is a validation guard around the exceptional path. The intended operational outcome is boring: ordinary ICMP behavior should remain unchanged, while the out-of-range extended reply case no longer reaches into the wrong lookup path.
In security engineering, boring is a compliment. The best fixes make the dangerous state unrepresentable or unreachable without changing the visible behavior everyone relies on.
There is no public basis, from the record provided, to call this a wormable disaster. There is also no public basis to wave it away as irrelevant. The honest position is that it is a real upstream Linux kernel vulnerability in a network protocol path, fixed by stable commits, still awaiting NVD enrichment, with exploitability not fully characterized in the public summary.
That kind of ambiguity is common in kernel work. It is also uncomfortable for organizations that want every vulnerability to fit neatly into “critical now” or “ignore forever.” The real world provides many bugs that deserve timely patching even before they deserve emergency response.
The better metric here is not fear but friction. If updating affected Linux kernels in your environment is routine, this CVE should be handled routinely and promptly. If updating them is difficult, the bug has exposed an operational weakness regardless of whether it becomes famous.
Distribution lag will vary. Some vendors may already have the relevant commits in testing or security-update channels. Others may fold them into broader kernel rollups. Cloud images and managed platforms may update on their own schedules, while self-managed hosts remain the customer’s responsibility.
The operational challenge is mapping CVE identity to package reality. A system may not show “CVE-2026-46037” in an obvious way until distro advisories catch up. The fixed state may be represented by a kernel package version, a vendor erratum, or a custom backport that does not match upstream version numbers neatly.
That is why kernel patch management cannot depend only on upstream commit hashes. Administrators need both sides of the map: the upstream issue and the downstream package that resolves it. Security scanners are useful here, but they are not substitutes for vendor advisories and actual kernel version verification.
The practical response is not to turn every Windows admin into a kernel developer. It is to make Linux kernel exposure visible in the same asset and vulnerability systems used for Windows. If a Linux host runs production workloads, terminates network traffic, supports development pipelines, or sits in a privileged management zone, it belongs in the same risk conversation.
Containers make this especially important. A container image can be patched endlessly and still share a vulnerable host kernel. CVE-2026-46037 is a reminder that the kernel boundary remains the real boundary. If the host kernel is wrong, every workload above it inherits some portion of that risk.
WSL deserves a more measured note. Developers should keep WSL and its kernel updated, but a workstation WSL instance is usually a different threat model than a public Linux server. The broader lesson is asset awareness, not panic over every laptop.
More importantly, perimeter filtering does not solve internal exposure. Many serious incidents move laterally inside networks where ICMP is allowed or inconsistently controlled. Cloud security groups, overlay networks, container bridges, VPN interfaces, and service meshes complicate the idea that a single firewall rule eliminates the vulnerable input path.
A defense-in-depth posture can certainly restrict unnecessary ICMP traffic. But the primary remediation for a kernel bounds issue is to run a kernel with the fix. Everything else is risk reduction around the edges.
That distinction matters because mitigations age badly. Firewall exceptions accumulate. Temporary ACLs become folklore. Kernel patches, once deployed and rebooted into, remove the vulnerable code path from the machine.
The most concrete takeaways are straightforward:
icmp_pointers table before validation. The bug is small in code and large in symbolism: another reminder that the oldest parts of the network stack remain security-sensitive because they sit directly on the packet path. There is no NVD severity score yet, no public exploitation claim in the record, and no reason for Windows desktop users to panic. But for anyone running Linux servers, appliances, WSL-adjacent infrastructure, containers on Linux hosts, or network-facing embedded systems, this is precisely the kind of kernel fix that should not be ignored because it looks boring.
A Tiny ICMP Edge Case Lands in the Kernel’s Most Exposed Neighborhood
The vulnerability sits in IPv4 ICMP handling, the part of the kernel responsible for the Internet Control Message Protocol messages that underpin diagnostics and error signaling. ICMP is best known through ping, but it is not merely a troubleshooting toy; it is a control channel that routers, hosts, and kernels use to report reachability, redirection, fragmentation, timing, and probing information.The specific issue concerns extended echo replies. These use
ICMP_EXT_ECHOREPLY as an outbound reply type, but that value sits outside the range described by the kernel’s icmp_pointers[] table, which covers the traditional ICMP type set up to NR_ICMP_TYPES. The fixed code avoids consulting that table when the reply type is outside range and uses array_index_nospec() for the remaining in-range lookup.That sounds like a narrow bounds-checking patch because it is one. Yet narrow bounds-checking patches in kernel packet parsers deserve more attention than their plain-language summaries usually receive. The mistake is not that ICMP is new, exotic, or unusually complex; the mistake is that a newer ICMP variant brushed against an older table assumption and the code did not draw the boundary early enough.
The important phrase in the CVE description is “before using.” Security bugs often live in that tiny ordering gap. Validate the type before indexing the table, and the code behaves as intended. Trust the type long enough to use it as an index, and the kernel may consult memory in a way the programmer did not mean.
The Absence of a Score Is Not the Same as the Absence of Risk
At publication, NVD had marked CVE-2026-46037 as awaiting enrichment and had not assigned CVSS 4.0, CVSS 3.x, or CVSS 2.0 metrics. That creates an awkward gap for IT teams that still use CVSS as the first triage gate. The vulnerability exists, the upstream fix exists, stable kernel commits exist, but the familiar red-yellow-green severity badge has not yet arrived.This is increasingly normal for Linux kernel CVEs. Since kernel.org became a more direct source for CVE records, many entries have appeared as terse descriptions of resolved kernel commits rather than fully scored advisories with exploit narratives, product matrices, and vendor-specific remediation language. That is efficient for developers and often frustrating for defenders.
The danger is that teams may read “N/A” as “not important.” That is the wrong lesson. “N/A” here means the enrichment process has not supplied a score yet, not that the bug has been judged harmless.
The better triage question is not “What number did NVD assign?” It is “Do I run affected Linux kernels on machines that receive untrusted network traffic?” For most servers, routers, firewalls, NAS devices, Kubernetes nodes, hypervisors, and appliance-like systems, the answer is yes.
The Patch Tells the Story Better Than the CVE Page
The CVE text is unusually direct. Extended echo replies use a reply type outside the range covered byicmp_pointers[]. The fix prevents the kernel from consulting that array for out-of-range reply types and adds array_index_nospec() for the in-range lookup.That second part is worth pausing on.
array_index_nospec() is a kernel helper used to harden array indexing against speculative execution abuse after bounds checks. Its presence does not automatically mean this CVE is a Spectre-class disclosure bug in the dramatic marketing sense. It does mean the maintainers decided the correct fix was not merely a conventional bounds check, but a bounds check hardened in the style now expected for sensitive indexes influenced by external input.The result is a patch that does two things at once. It restores ordinary memory-safety discipline by refusing to index outside the valid table range. It also narrows the speculative execution window for valid indexes.
That combination is now a pattern in mature kernel code. The kernel does not just ask whether C will execute the right branch architecturally; it also asks whether the processor might transiently wander through a path that leaks information. For sysadmins, the practical conclusion is simpler: take the stable update when your distribution ships it.
Old Protocols Keep Producing New Bugs Because Their Assumptions Keep Changing
ICMP is one of those protocols administrators think they understand because they have usedping for decades. But kernel protocol code is not frozen museum glass. It evolves around new extensions, hardware offloads, namespaces, tunneling, filtering, rate limiting, and increasingly subtle hardening rules.Extended echo is a good example of how a benign expansion can expose a stale assumption. A table built around traditional ICMP types is not necessarily wrong. A reply path that assumes every reply type fits that table is.
This is how legacy infrastructure accumulates modern vulnerabilities. The failure is rarely a single catastrophic design decision. More often, it is the slow mismatch between old enumerations, new protocol behavior, and code paths that were never re-audited under the new assumption.
That matters because network stacks are full of such seams. IPv4 and IPv6 coexist. Tunnels wrap packets inside packets. Namespaces make one host look like many. Containers turn host kernels into shared infrastructure for mutually distrusting workloads. A bug that once would have been “just a host network oddity” can now live at the boundary between tenant and platform.
Windows Readers Should Care Because Linux Is Already in Their Estate
This is WindowsForum, so the obvious question is why a Linux kernel ICMP CVE belongs here. The answer is that very few Windows environments are purely Windows anymore. Linux runs under Windows Subsystem for Linux, inside developer workstations, across cloud fleets, on security appliances, in CI/CD systems, inside NAS boxes, and beneath many container platforms that Windows administrators still have to account for.WSL itself is not the same exposure model as an internet-facing Linux server. A developer’s WSL instance is generally not the first place to panic over a remote ICMP edge case. But organizations that treat Linux as somebody else’s problem because the endpoint fleet is Windows are kidding themselves.
The more realistic enterprise map is hybrid. Windows endpoints authenticate against cloud identity, deploy code to Linux runners, administer Linux appliances, and connect to container hosts running workloads that the desktop team may never directly touch. A kernel networking fix may therefore matter to the same organization even if it does not matter to the same machine.
This is also a supply-chain problem in miniature. Many appliances do not advertise their kernel pedigree loudly. Firewalls, VPN concentrators, storage systems, monitoring probes, hyperconverged nodes, and industrial gateways may all include Linux kernels whose update cadence depends on a vendor firmware pipeline rather than the distro package manager an admin can control directly.
The Likely Attack Surface Is Narrow, But It Is Still Packet-Reachable
The CVE record does not currently claim active exploitation, provide a proof of concept, or describe a complete impact chain such as privilege escalation, remote code execution, or denial of service. That uncertainty should be preserved. Overstating this bug would be as irresponsible as ignoring it.What we can say is that the vulnerable code path is in network-facing kernel ICMP handling. That makes it different from a local-only driver bug buried behind obscure hardware. The potentially relevant input arrives as packets, and packet-reachable kernel parsing is exactly the class of code defenders patch quickly because the margin for error is smaller.
The most conservative interpretation is that CVE-2026-46037 is a correctness and hardening fix for an out-of-range array consultation in an ICMP reply path. The more security-minded interpretation is that any out-of-range table use in the kernel network stack deserves prompt remediation before researchers or attackers turn the terse commit message into a working crash or leak primitive.
Those interpretations are not mutually exclusive. Kernel security often starts as correctness work. The exploitability of a bug may be unclear at disclosure, but the value of removing undefined or out-of-bounds behavior from packet-handling code is not.
The Real Operational Risk Is Patch Latency, Not Mystery Severity
For enterprise administrators, the operational playbook is less dramatic than the vulnerability headline. Inventory Linux kernels. Check whether distribution maintainers have shipped backports. Prioritize internet-facing and untrusted-network-facing systems. Then patch through normal tested channels.The trap is waiting for perfect information. By the time every downstream vendor publishes a polished advisory, every scanner plugin is updated, and every dashboard has a severity score, the straightforward patch window may already have been missed. That does not mean emergency reboot every Linux machine on the planet. It does mean this CVE should enter the next kernel maintenance cycle rather than languish in a “no score, no action” queue.
Rolling fleets make this easier. Immutable images, staged node drains, live migration, and blue-green appliance pairs all exist to make kernel updates less theatrical. If a Linux kernel update still requires a heroic weekend outage, CVE-2026-46037 is less the cause of pain than a reminder that the update process itself needs modernization.
The hardest cases will be vendor-controlled devices. If the kernel is embedded in an appliance, customers may not be able to apply the upstream stable commits directly. In those cases, the right move is to ask the vendor whether their shipped kernel contains the affected ICMP code and whether the relevant stable patches have been incorporated.
Kernel.org’s CVE Style Rewards Readers Who Follow the Patch Trail
One striking feature of this CVE is how little narrative packaging surrounds it. The record states the resolved issue, lists stable commit references, and leaves scoring empty pending enrichment. That is not a glossy advisory; it is a breadcrumb trail from vulnerability identifier to kernel patch.This is good for speed and bad for casual comprehension. Developers can recognize the affected function family and inspect the fix. Many security teams, however, are left translating a commit-style description into business risk.
The shift places more burden on downstream distributions. Red Hat, Canonical, SUSE, Debian, cloud vendors, and appliance makers still have to convert upstream kernel fixes into the language administrators use: affected versions, fixed package names, reboot requirements, mitigations, and severity ratings. Until that happens, the upstream CVE exists in a kind of operational half-light.
That half-light is where mistakes happen. One team dismisses the bug because NVD has no CVSS score. Another treats every kernel CVE as a five-alarm fire. The mature answer sits between those extremes: understand the code path, understand the exposure, patch according to asset criticality, and avoid inventing certainty where the public record has not supplied it.
The ICMP Detail That Matters Is the Boundary Between Traditional and Extended Behavior
The vulnerable assumption is almost architectural.icmp_pointers[] describes traditional ICMP types up to NR_ICMP_TYPES. Extended echo replies use a value beyond that range. A path that treats the extended reply type as though it belongs to the traditional table has crossed a boundary the code needed to enforce.This is why the fix is conceptually clean. Do not consult the traditional table for a nontraditional type. For types that do belong to the table, use a speculation-safe index helper. Normal ICMP replies continue to behave as before.
That last point is important for administrators worried about regressions. The patch is not a redesign of ICMP handling. It is a validation guard around the exceptional path. The intended operational outcome is boring: ordinary ICMP behavior should remain unchanged, while the out-of-range extended reply case no longer reaches into the wrong lookup path.
In security engineering, boring is a compliment. The best fixes make the dangerous state unrepresentable or unreachable without changing the visible behavior everyone relies on.
The Security Industry Will Be Tempted to Overmarket This
Kernel CVEs have become easy fuel for alarm. A packet, a kernel, an out-of-bounds access, and a missing CVSS score are enough ingredients for a dozen breathless posts promising remote compromise or mass exploitation. CVE-2026-46037 does not currently justify that level of certainty.There is no public basis, from the record provided, to call this a wormable disaster. There is also no public basis to wave it away as irrelevant. The honest position is that it is a real upstream Linux kernel vulnerability in a network protocol path, fixed by stable commits, still awaiting NVD enrichment, with exploitability not fully characterized in the public summary.
That kind of ambiguity is common in kernel work. It is also uncomfortable for organizations that want every vulnerability to fit neatly into “critical now” or “ignore forever.” The real world provides many bugs that deserve timely patching even before they deserve emergency response.
The better metric here is not fear but friction. If updating affected Linux kernels in your environment is routine, this CVE should be handled routinely and promptly. If updating them is difficult, the bug has exposed an operational weakness regardless of whether it becomes famous.
The Patch Queue Is the Signal Administrators Should Not Miss
The concrete record shows multiple stable kernel commit references associated with the fix. That means the maintainers considered the correction appropriate for supported stable branches, not merely a theoretical cleanup in future mainline code. Stable backports are one of the clearest signals administrators get from the kernel ecosystem: this is a fix you are meant to consume.Distribution lag will vary. Some vendors may already have the relevant commits in testing or security-update channels. Others may fold them into broader kernel rollups. Cloud images and managed platforms may update on their own schedules, while self-managed hosts remain the customer’s responsibility.
The operational challenge is mapping CVE identity to package reality. A system may not show “CVE-2026-46037” in an obvious way until distro advisories catch up. The fixed state may be represented by a kernel package version, a vendor erratum, or a custom backport that does not match upstream version numbers neatly.
That is why kernel patch management cannot depend only on upstream commit hashes. Administrators need both sides of the map: the upstream issue and the downstream package that resolves it. Security scanners are useful here, but they are not substitutes for vendor advisories and actual kernel version verification.
The Windows Admin’s Linux Checklist Is Getting Longer
Windows administrators increasingly inherit Linux risk without inheriting Linux culture. They may own the endpoint, the identity plane, the management tooling, or the virtualization stack while Linux appears as the substrate for something else. That makes kernel CVEs easy to miss because they do not announce themselves through the traditional Windows Update workflow.The practical response is not to turn every Windows admin into a kernel developer. It is to make Linux kernel exposure visible in the same asset and vulnerability systems used for Windows. If a Linux host runs production workloads, terminates network traffic, supports development pipelines, or sits in a privileged management zone, it belongs in the same risk conversation.
Containers make this especially important. A container image can be patched endlessly and still share a vulnerable host kernel. CVE-2026-46037 is a reminder that the kernel boundary remains the real boundary. If the host kernel is wrong, every workload above it inherits some portion of that risk.
WSL deserves a more measured note. Developers should keep WSL and its kernel updated, but a workstation WSL instance is usually a different threat model than a public Linux server. The broader lesson is asset awareness, not panic over every laptop.
The ICMP Filter Is Not a Substitute for the Kernel Fix
Some organizations may ask whether blocking ICMP mitigates the issue. Network filtering can reduce exposure in some environments, particularly at internet edges, but it is not a clean substitute for the kernel patch. ICMP has legitimate uses, and blanket filtering can break diagnostics, path MTU discovery, monitoring, and operational visibility.More importantly, perimeter filtering does not solve internal exposure. Many serious incidents move laterally inside networks where ICMP is allowed or inconsistently controlled. Cloud security groups, overlay networks, container bridges, VPN interfaces, and service meshes complicate the idea that a single firewall rule eliminates the vulnerable input path.
A defense-in-depth posture can certainly restrict unnecessary ICMP traffic. But the primary remediation for a kernel bounds issue is to run a kernel with the fix. Everything else is risk reduction around the edges.
That distinction matters because mitigations age badly. Firewall exceptions accumulate. Temporary ACLs become folklore. Kernel patches, once deployed and rebooted into, remove the vulnerable code path from the machine.
The Quiet Fixes Are the Ones Patch Programs Are Built For
CVE-2026-46037 is not a blockbuster vulnerability, at least not on the public facts available now. It is a quiet kernel fix in a quiet protocol path, published with minimal scoring information and a concise technical description. That makes it a useful test of whether an organization’s patch program handles routine kernel risk or only reacts to branded emergencies.The most concrete takeaways are straightforward:
- CVE-2026-46037 was published on May 27, 2026, and concerns Linux IPv4 ICMP handling for extended echo replies.
- The issue is that
ICMP_EXT_ECHOREPLYcan sit outside the range covered byicmp_pointers[], so the kernel must validate the reply type before consulting that table. - NVD had not assigned CVSS metrics at publication, so the absence of a score should not be treated as a finding of low severity.
- The fix preserves normal ICMP reply behavior while preventing the out-of-range lookup and hardening in-range indexing with
array_index_nospec(). - Administrators should prioritize patched kernels for Linux systems exposed to untrusted networks, including servers, appliances, container hosts, and cloud nodes.
- Windows-centric shops should still track this CVE if Linux appears in WSL, infrastructure tooling, appliances, CI/CD, virtualization, or container platforms.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:03:06-07:00
NVD - CVE-2026-46037
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:03:06-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2006-0454 - Linux kernel ICMP Response Crash
Linux kernel before 2.6.15.3 down to 2.6.12, while constructing an ICMP response in icmp_send, does not properly handle when the ip_options_echo function in icmp.c fails, which allows remote attackers to cause a denial of service (crash) via vectors such as (1) record-route and (2) timestamp IP...cvefeed.io
- Related coverage: kernel.googlesource.com
- Related coverage: linux.googlesource.com
- Related coverage: citeseerx.ist.psu.edu
- Related coverage: support.bull.com
- Related coverage: nscpolteksby.ac.id
