CVE-2026-46137 was published by NVD on May 28, 2026, for a Linux kernel Multipath TCP path-manager race in the ADD_ADDR retransmission timer, fixed upstream by taking the socket lock in softirq context and retrying shortly when user context owns the socket. The terse advisory makes it look like another minor kernel bookkeeping CVE. It is more usefully read as a reminder that modern Windows estates increasingly inherit Linux networking risk through WSL, containers, appliances, edge gateways, and vendor-managed virtual machines. The practical lesson is not panic; it is inventory.
The vulnerability sits in Linux’s Multipath TCP implementation, specifically in the path-manager code that retransmits ADD_ADDR messages. ADD_ADDR is part of the mechanism by which an MPTCP endpoint tells its peer that another address is available for the same connection. In plain English, it is one of the pieces that lets a single logical TCP connection span multiple network paths.
The bug report says the timer helper
The fix is correspondingly unglamorous. The callback now takes the socket lock with
That is why CVE-2026-46137 currently has no NVD-assigned CVSS score. The public text establishes a race and a fix, not an exploit narrative. There is no public evidence in the CVE record of remote code execution, privilege escalation, or a weaponized proof of concept.
But the absence of a score is not the same thing as the absence of operational relevance. Kernel CVEs often begin life as commit messages, and the security industry then tries to reverse-map impact from code paths, configurations, and deployment patterns. This one is a good example of why that process is messy.
Linux gained upstream MPTCP support in the 5.6 era, and the implementation has matured through years of incremental fixes. That matters because CVE-2026-46137 is not a newly invented subsystem bolted onto yesterday’s kernel. It is part of a long-running effort to make Linux’s TCP stack more capable in the messy networks people actually use.
The bug is in the path-manager machinery, not in a broad “all TCP traffic is broken” zone. A Windows user browsing the web through ordinary TCP on the NT kernel is not suddenly exposed because NVD published a Linux MPTCP CVE. The affected code has to exist in the running Linux kernel, and the relevant MPTCP functionality has to be reachable.
That distinction is important for WindowsForum readers because “Linux kernel vulnerability” now cuts across more than Linux desktops and servers. WSL 2 runs a real Linux kernel. Container hosts run Linux kernels. Many network appliances, storage boxes, security tools, Kubernetes nodes, NAS devices, routers, SD-WAN boxes, and cloud images do the same.
The attack surface therefore depends less on the logo on the laptop and more on where Linux is actually running. In 2026, that answer is “almost everywhere,” including plenty of shops that still describe themselves as Windows-first.
The public description for CVE-2026-46137, however, points to a narrow corrective pattern. The timer callback was touching socket state without holding the bottom-half-aware socket lock. The fix does not add a new validation policy, block malformed packets, or reject an attacker-controlled field. It restores the expected concurrency discipline around a socket.
That makes the most likely operational symptoms subtle: instability, warnings, rare crashes, or connection-management weirdness under timing pressure. The CVE text does not prove that an attacker can reliably trigger those effects from the network, nor does it rule it out. Kernel races live in the gap between “the code is wrong” and “the exploit is practical.”
This is where administrators should resist two bad instincts. The first is to dismiss the issue because it lacks a dramatic CVSS number. The second is to treat every kernel race as a five-alarm incident. The better response is to ask whether your kernels include MPTCP, whether your workloads use it, and whether your vendors have already shipped the stable backport.
The kernel.org references attached to the CVE indicate that the fix has been propagated through stable branches. That is the signal operators need. In the kernel world, the patch often matters more than the prose around it.
The catch is that modern Windows environments routinely run Linux in places administrators may forget to count. Developers use WSL 2. Security teams deploy Linux-based sensors. Backup, VPN, observability, and network-monitoring vendors ship hardened Linux appliances. Azure and on-prem virtualization stacks are full of Linux guests managed by teams whose primary identity is still Microsoft infrastructure.
WSL 2 deserves particular care in the discussion. Microsoft’s WSL 2 architecture uses a Linux kernel delivered separately from the Windows image, and users can also configure a custom kernel. That does not automatically mean every WSL 2 installation is exposed to this specific MPTCP bug. In many default developer setups, MPTCP may not be enabled or meaningfully reachable.
Custom kernels are the wrinkle. The moment a developer or platform team builds its own WSL kernel to enable niche networking features, attach unusual modules, or mirror a production Linux environment, the patch state becomes their responsibility. WSL makes Linux feel like a Windows feature, but custom kernel maintenance is still Linux kernel maintenance.
For enterprise administrators, the more likely exposure is not an individual WSL shell. It is the Linux VM or appliance sitting in a network path, often with multiple interfaces, exactly the kind of environment where MPTCP-like functionality is more plausible. The vulnerability may be narrow, but the inventory problem is broad.
That delay creates a dangerous vacuum. Patch-management tools may ingest the CVE before they have a severity score. Vulnerability dashboards may show “N/A” where managers expect red, yellow, or green. Teams that depend too heavily on CVSS can end up doing nothing because the field they sort by is empty.
Linux kernel CVEs make this especially awkward because kernel.org’s CNA process tends to assign CVEs to resolved defects at high volume. Many are correctness fixes with security implications rather than fully characterized vulnerabilities. That is a good thing for transparency, but it is uncomfortable for organizations that want every CVE to arrive pre-labeled with a business impact.
CVE-2026-46137 is exactly the kind of record that exposes the weakness of score-first triage. The right initial question is not “is the base score high?” It is “do we run affected kernels in contexts where MPTCP is enabled or reachable, and do we have a vendor update?” A missing number should slow judgment, not stop action.
That tells us several things. First, the bug is about concurrent access to socket state. Second, the kernel developers viewed delaying the timer as safer than racing with user-owned socket operations. Third, the fix is suitable for stable kernels, which means maintainers considered it appropriate to backport rather than leave only in bleeding-edge development.
The “Fixes” tag points back to the earlier change that added ADD_ADDR retransmission after timeout. That is another useful clue. Vulnerabilities often enter through feature work that is reasonable at the time but misses one execution context. A retransmission timer is necessary for reliability; the bug was not the feature but the missing locking discipline around the feature.
This is how kernel security usually looks in practice. It is not always a cinematic exploit chain. It is a small concurrency assumption corrected after review, testing, or bug discovery, then pushed through stable trees and eventually surfaced to scanners as a CVE.
For defenders, that means the remediation path is refreshingly boring. Update to a kernel release that includes the backport. If you consume kernels from a distribution or vendor appliance, wait for and apply that vendor’s package. If you maintain custom kernels, pull the appropriate stable commit and rebuild.
That is where a CVE like this can linger. A load balancer, SD-WAN gateway, backup appliance, monitoring sensor, lab router, NAS, or container host may run a kernel old enough to contain the bug and customized enough that ordinary package guidance does not apply. If the vendor firmware cadence is slow, the organization may not even see the fix until a quarterly rollup.
The MPTCP angle narrows the field somewhat. Systems with multiple interfaces, failover paths, mobility features, or specialized transport behavior deserve more attention than single-homed throwaway VMs. Still, administrators should not assume that a feature is disabled simply because no one remembers enabling it.
There is also a class of risk around high-density Linux hosts. Even when the vulnerability is not obviously remote-exploitable, kernel races can become denial-of-service concerns under load, especially in environments where untrusted workloads can influence networking behavior. Multi-tenant systems and CI runners deserve a more conservative patch posture than isolated lab machines.
The central lesson is that the asset inventory has to include the kernel, not just the operating system name. “Ubuntu appliance,” “vendor virtual machine,” and “WSL custom kernel” are not patch states. They are starting points for questions.
CVE-2026-46137 is not noisy in the sense of being meaningless. It describes a real race in a real subsystem with a real fix. But it is noisy in the operational sense because its severity depends heavily on configuration, workload, and deployment context.
Security teams need to adapt their playbooks accordingly. A kernel CVE with no CVSS score should trigger enrichment inside the organization: affected kernel versions, enabled configs, reachable features, vendor status, exploit chatter, and compensating controls. Waiting for NVD to complete the record may be acceptable for a desktop peripheral bug; it is less defensible for kernel networking on exposed infrastructure.
The inverse is also true. Not every Linux kernel CVE warrants emergency downtime. If MPTCP is absent from the kernel, disabled, or unreachable in your environment, the urgency changes. The goal is evidence-based prioritization, not CVE maximalism.
This is uncomfortable for executives because it resists the simplicity of a single severity number. It is healthier for engineers because it pushes the conversation back toward systems reality.
For a developer using WSL 2, the first question is whether they are on Microsoft’s provided kernel or a custom one. If they use the default kernel, the update path is tied to Microsoft’s WSL kernel servicing. If they use a hand-built kernel, they should treat it like any other self-maintained Linux kernel and track stable fixes.
For a sysadmin, the issue belongs in the same queue as other Linux kernel stable updates, with priority bumped for systems using advanced networking or multiple paths. That includes servers where MPTCP is explicitly enabled, experimental networking stacks, and appliances that may not expose their kernel configuration cleanly.
For a security team, the absence of a CVSS score should not block triage. The record was published on May 28, 2026, and the change history points to kernel.org as the source. That is enough to open an internal ticket, map affected systems, and monitor vendor advisories.
The most important practical point is that remediation is not a registry tweak, a Windows Defender signature, or a firewall rule. It is a kernel update, delivered through the channel that owns the affected Linux kernel.
A Small Race Lands in a Large Dependency Graph
The vulnerability sits in Linux’s Multipath TCP implementation, specifically in the path-manager code that retransmits ADD_ADDR messages. ADD_ADDR is part of the mechanism by which an MPTCP endpoint tells its peer that another address is available for the same connection. In plain English, it is one of the pieces that lets a single logical TCP connection span multiple network paths.The bug report says the timer helper
mptcp_pm_add_timer() runs as a timer callback in softirq context. That sentence is doing most of the work. Kernel timer callbacks are not ordinary application code; they run inside the kernel’s deferred interrupt machinery, where concurrency assumptions are unforgiving and a missing lock can become a data race.The fix is correspondingly unglamorous. The callback now takes the socket lock with
bh_lock_sock(), checks whether the socket is already owned by user context, and if so reschedules the timer for a short interval rather than charging ahead. That mirrors the pattern used by keepalive timers: if the object is busy, wait and come back.That is why CVE-2026-46137 currently has no NVD-assigned CVSS score. The public text establishes a race and a fix, not an exploit narrative. There is no public evidence in the CVE record of remote code execution, privilege escalation, or a weaponized proof of concept.
But the absence of a score is not the same thing as the absence of operational relevance. Kernel CVEs often begin life as commit messages, and the security industry then tries to reverse-map impact from code paths, configurations, and deployment patterns. This one is a good example of why that process is messy.
MPTCP Is Niche Until It Is Suddenly in Your Path
Multipath TCP has always occupied an odd place in the networking stack. It is a real protocol with a real purpose: keep one connection alive and efficient across several paths, such as Wi-Fi plus cellular, multiple uplinks, or redundant enterprise links. It is also not something most desktop users knowingly enable or tune.Linux gained upstream MPTCP support in the 5.6 era, and the implementation has matured through years of incremental fixes. That matters because CVE-2026-46137 is not a newly invented subsystem bolted onto yesterday’s kernel. It is part of a long-running effort to make Linux’s TCP stack more capable in the messy networks people actually use.
The bug is in the path-manager machinery, not in a broad “all TCP traffic is broken” zone. A Windows user browsing the web through ordinary TCP on the NT kernel is not suddenly exposed because NVD published a Linux MPTCP CVE. The affected code has to exist in the running Linux kernel, and the relevant MPTCP functionality has to be reachable.
That distinction is important for WindowsForum readers because “Linux kernel vulnerability” now cuts across more than Linux desktops and servers. WSL 2 runs a real Linux kernel. Container hosts run Linux kernels. Many network appliances, storage boxes, security tools, Kubernetes nodes, NAS devices, routers, SD-WAN boxes, and cloud images do the same.
The attack surface therefore depends less on the logo on the laptop and more on where Linux is actually running. In 2026, that answer is “almost everywhere,” including plenty of shops that still describe themselves as Windows-first.
The Race Is Real, the Blast Radius Is Conditional
A data race in kernel networking code is never comforting. The kernel is shared state made executable, and networking code is both complex and externally stimulated. Races can produce anything from harmless retransmission oddities to memory corruption, use-after-free behavior, or exploitable state confusion, depending on the exact objects involved.The public description for CVE-2026-46137, however, points to a narrow corrective pattern. The timer callback was touching socket state without holding the bottom-half-aware socket lock. The fix does not add a new validation policy, block malformed packets, or reject an attacker-controlled field. It restores the expected concurrency discipline around a socket.
That makes the most likely operational symptoms subtle: instability, warnings, rare crashes, or connection-management weirdness under timing pressure. The CVE text does not prove that an attacker can reliably trigger those effects from the network, nor does it rule it out. Kernel races live in the gap between “the code is wrong” and “the exploit is practical.”
This is where administrators should resist two bad instincts. The first is to dismiss the issue because it lacks a dramatic CVSS number. The second is to treat every kernel race as a five-alarm incident. The better response is to ask whether your kernels include MPTCP, whether your workloads use it, and whether your vendors have already shipped the stable backport.
The kernel.org references attached to the CVE indicate that the fix has been propagated through stable branches. That is the signal operators need. In the kernel world, the patch often matters more than the prose around it.
Windows Estates Are Not Exempt Just Because NT Is Not Affected
This CVE does not describe a Windows kernel flaw. It does not implicate SMB, RDP, WinSock, Hyper-V’s Windows components, or the NT networking stack. If your mental model is “Windows vulnerability equals Windows Update,” CVE-2026-46137 sits outside that lane.The catch is that modern Windows environments routinely run Linux in places administrators may forget to count. Developers use WSL 2. Security teams deploy Linux-based sensors. Backup, VPN, observability, and network-monitoring vendors ship hardened Linux appliances. Azure and on-prem virtualization stacks are full of Linux guests managed by teams whose primary identity is still Microsoft infrastructure.
WSL 2 deserves particular care in the discussion. Microsoft’s WSL 2 architecture uses a Linux kernel delivered separately from the Windows image, and users can also configure a custom kernel. That does not automatically mean every WSL 2 installation is exposed to this specific MPTCP bug. In many default developer setups, MPTCP may not be enabled or meaningfully reachable.
Custom kernels are the wrinkle. The moment a developer or platform team builds its own WSL kernel to enable niche networking features, attach unusual modules, or mirror a production Linux environment, the patch state becomes their responsibility. WSL makes Linux feel like a Windows feature, but custom kernel maintenance is still Linux kernel maintenance.
For enterprise administrators, the more likely exposure is not an individual WSL shell. It is the Linux VM or appliance sitting in a network path, often with multiple interfaces, exactly the kind of environment where MPTCP-like functionality is more plausible. The vulnerability may be narrow, but the inventory problem is broad.
NVD’s “Awaiting Enrichment” Label Is a Warning About Process, Not Just Data
NVD marks this CVE as awaiting enrichment, with no NIST CVSS vector yet. That has become increasingly common for kernel records, and it changes how defenders should read the database. The CVE exists, the upstream project has described the resolved flaw, but the familiar severity shorthand is not yet there.That delay creates a dangerous vacuum. Patch-management tools may ingest the CVE before they have a severity score. Vulnerability dashboards may show “N/A” where managers expect red, yellow, or green. Teams that depend too heavily on CVSS can end up doing nothing because the field they sort by is empty.
Linux kernel CVEs make this especially awkward because kernel.org’s CNA process tends to assign CVEs to resolved defects at high volume. Many are correctness fixes with security implications rather than fully characterized vulnerabilities. That is a good thing for transparency, but it is uncomfortable for organizations that want every CVE to arrive pre-labeled with a business impact.
CVE-2026-46137 is exactly the kind of record that exposes the weakness of score-first triage. The right initial question is not “is the base score high?” It is “do we run affected kernels in contexts where MPTCP is enabled or reachable, and do we have a vendor update?” A missing number should slow judgment, not stop action.
The Patch Says More Than the CVE Record
The upstream patch is compact, which is often a gift. It adds socket locking around a timer path, detects user ownership of the socket, and retries later. No sprawling refactor is required to understand the intent.That tells us several things. First, the bug is about concurrent access to socket state. Second, the kernel developers viewed delaying the timer as safer than racing with user-owned socket operations. Third, the fix is suitable for stable kernels, which means maintainers considered it appropriate to backport rather than leave only in bleeding-edge development.
The “Fixes” tag points back to the earlier change that added ADD_ADDR retransmission after timeout. That is another useful clue. Vulnerabilities often enter through feature work that is reasonable at the time but misses one execution context. A retransmission timer is necessary for reliability; the bug was not the feature but the missing locking discipline around the feature.
This is how kernel security usually looks in practice. It is not always a cinematic exploit chain. It is a small concurrency assumption corrected after review, testing, or bug discovery, then pushed through stable trees and eventually surfaced to scanners as a CVE.
For defenders, that means the remediation path is refreshingly boring. Update to a kernel release that includes the backport. If you consume kernels from a distribution or vendor appliance, wait for and apply that vendor’s package. If you maintain custom kernels, pull the appropriate stable commit and rebuild.
The Real Risk Is the Appliance You Forgot
Most Windows-heavy organizations are good at tracking Windows cumulative updates. They are usually decent at tracking mainstream Linux servers. They are often much worse at tracking the embedded Linux systems that sit between those worlds.That is where a CVE like this can linger. A load balancer, SD-WAN gateway, backup appliance, monitoring sensor, lab router, NAS, or container host may run a kernel old enough to contain the bug and customized enough that ordinary package guidance does not apply. If the vendor firmware cadence is slow, the organization may not even see the fix until a quarterly rollup.
The MPTCP angle narrows the field somewhat. Systems with multiple interfaces, failover paths, mobility features, or specialized transport behavior deserve more attention than single-homed throwaway VMs. Still, administrators should not assume that a feature is disabled simply because no one remembers enabling it.
There is also a class of risk around high-density Linux hosts. Even when the vulnerability is not obviously remote-exploitable, kernel races can become denial-of-service concerns under load, especially in environments where untrusted workloads can influence networking behavior. Multi-tenant systems and CI runners deserve a more conservative patch posture than isolated lab machines.
The central lesson is that the asset inventory has to include the kernel, not just the operating system name. “Ubuntu appliance,” “vendor virtual machine,” and “WSL custom kernel” are not patch states. They are starting points for questions.
Kernel CVEs Are Becoming More Honest and Less Convenient
The Linux kernel’s modern CVE flow is a cultural change as much as a security process change. More fixes are being assigned identifiers, often with terse descriptions that mirror upstream commit messages. That gives defenders more visibility into what changed, but it also creates noise for anyone expecting every CVE to arrive with a polished advisory and an exploitability verdict.CVE-2026-46137 is not noisy in the sense of being meaningless. It describes a real race in a real subsystem with a real fix. But it is noisy in the operational sense because its severity depends heavily on configuration, workload, and deployment context.
Security teams need to adapt their playbooks accordingly. A kernel CVE with no CVSS score should trigger enrichment inside the organization: affected kernel versions, enabled configs, reachable features, vendor status, exploit chatter, and compensating controls. Waiting for NVD to complete the record may be acceptable for a desktop peripheral bug; it is less defensible for kernel networking on exposed infrastructure.
The inverse is also true. Not every Linux kernel CVE warrants emergency downtime. If MPTCP is absent from the kernel, disabled, or unreachable in your environment, the urgency changes. The goal is evidence-based prioritization, not CVE maximalism.
This is uncomfortable for executives because it resists the simplicity of a single severity number. It is healthier for engineers because it pushes the conversation back toward systems reality.
The WindowsForum Reader’s Version of the Risk
For a home Windows user, this CVE is probably a non-event unless they run Linux kernels directly through WSL 2, virtual machines, routers, NAS devices, or custom networking gear. Even then, ordinary update hygiene is the answer. There is no indication from the public record that this is a mass-exploitation event targeting consumer Windows machines.For a developer using WSL 2, the first question is whether they are on Microsoft’s provided kernel or a custom one. If they use the default kernel, the update path is tied to Microsoft’s WSL kernel servicing. If they use a hand-built kernel, they should treat it like any other self-maintained Linux kernel and track stable fixes.
For a sysadmin, the issue belongs in the same queue as other Linux kernel stable updates, with priority bumped for systems using advanced networking or multiple paths. That includes servers where MPTCP is explicitly enabled, experimental networking stacks, and appliances that may not expose their kernel configuration cleanly.
For a security team, the absence of a CVSS score should not block triage. The record was published on May 28, 2026, and the change history points to kernel.org as the source. That is enough to open an internal ticket, map affected systems, and monitor vendor advisories.
The most important practical point is that remediation is not a registry tweak, a Windows Defender signature, or a firewall rule. It is a kernel update, delivered through the channel that owns the affected Linux kernel.
The Patch Queue Is the Security Boundary This Time
The concrete response to CVE-2026-46137 is not complicated, but it is easy to misplace because the affected code may live outside the team that reads the alert. Treat it as a kernel-maintenance issue with a networking-specific exposure profile.- Check whether any Linux kernels you operate include MPTCP support and whether MPTCP is enabled or used on systems with multiple network paths.
- Prioritize updates for Linux servers, appliances, container hosts, and network devices that sit in exposed or high-availability paths.
- Review WSL 2 systems separately if developers or platform teams use custom kernels rather than Microsoft’s serviced default kernel.
- Do not wait for an NVD CVSS score before determining whether your own environment is affected.
- For vendor appliances, track firmware or kernel advisories from the vendor rather than assuming distribution package status applies.
- If you build kernels internally, pull the relevant stable fix and document the backport in the same way you would document any production security patch.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:02:01-07:00
NVD - CVE-2026-46137
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:02:01-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH net 03/11] mptcp: pm: ADD_ADDR rtx: fix potential data-race — Linux Kernel
Linux Kernel: [PATCH net 03/11] mptcp: pm: ADD_ADDR rtx: fix potential data-race
www.spinics.net
- Related coverage: opennet.ru
- Related coverage: mail-archive.com
[PATCH net 00/11] mptcp: pm: misc. fixes for v7.1-rc3
www.mail-archive.com
- Related coverage: patchew.org
- Related coverage: gitlab.com
- Related coverage: lists-ec2.96boards.org
- Related coverage: datatracker.ietf.org
- Official source: learn.microsoft.com
How to use the Microsoft Linux kernel v6 on WSL2
Know how to build and use the Microsoft Linux kernel v6 on WSL2 instead of the stock kernellearn.microsoft.com - Related coverage: mptcp.dev
Setup
Multipath TCP (MPTCP) for Linux, an extension to TCP that enhances connection redundancy and performance by utilizing multiple underlying TCP sessions simultaneously. This site provides installation guides, debugging tools, FAQs, and a list of apps supporting MPTCP, aimed at facilitating the...
www.mptcp.dev
- Official source: github.com
GitHub - microsoft/WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2)
The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2) - microsoft/WSL2-Linux-Kernel
github.com
- Related coverage: kernel.org
- Related coverage: mptcp-apps.github.io
- Related coverage: kernelnewbies.org
Linux_5.6 - Linux Kernel Newbies
List of changes and new features merged in the Linux kernel during the 5.6 development cyclekernelnewbies.org - Related coverage: sourceforge.net
- Related coverage: en.linuxadictos.com
- Related coverage: archive.fosdem.org
- Related coverage: scottibyte.com
