CVE-2026-46015 is a Linux kernel TCP bug published by NVD on May 27, 2026, after kernel.org reported a missing listener wakeup during SO_REUSEPORT socket migration in the TCP accept path. The bug is not a flashy remote-code-execution headline, and NVD had not assigned CVSS severity at publication time. But it lands in exactly the kind of kernel machinery that modern service platforms depend on: load-sharing listeners, event loops, graceful restarts, and high-availability networking. The practical lesson is blunt: availability bugs in mature TCP paths still matter because production software increasingly treats readiness notification as truth.
At the center of CVE-2026-46015 is a deceptively ordinary promise. When a listening TCP socket has a connection ready to accept, software waiting on that listener should be told. That notification is the difference between a service that drains its accept queue and one that sits idle while work is already waiting in the kernel.
The flaw appears when Linux migrates an established child socket from a closing listener to another listener in the same
That distinction matters because nonblocking
In other words, the bug is not that Linux loses the connection. It is that Linux can fail to ring the bell.
That makes it attractive to web servers, proxies, RPC frameworks, service meshes, container platforms, and custom high-throughput daemons. It also helps with rolling restarts and worker replacement: one listener can close while others remain active, and the kernel can keep the port alive across process churn.
The migration behavior involved in this CVE is part of that more ambitious world. When a listener is closing, the kernel may migrate queued or partially processed connection state to another listener in the same reuseport group. That is the kind of feature administrators love because it turns process death or restart into a survivable event.
But the more the kernel hides lifecycle complexity from user space, the more important the exact notification semantics become. A migrated connection is only useful if the application knows it should wake up and accept it. CVE-2026-46015 is a reminder that load-balancing primitives are also correctness primitives.
Instead, the failure mode is operationally familiar: a listener appears healthy, the port remains open, some connections continue to work, and yet a worker or process waiting on readiness may never wake for a migrated accept entry. Depending on the service architecture, that could present as intermittent hangs, uneven load distribution, slow drains during reloads, or connections that appear to stall after a restart event.
That makes triage harder. A sysadmin may blame the application. A developer may blame an event-loop edge case. An SRE may suspect a proxy, a firewall, a Kubernetes readiness probe, or an unlucky race in deployment automation. The actual culprit sits lower: the kernel placed work on the target listener’s accept queue without performing the wakeup that readiness-driven software expects.
The bug also has a narrow trigger surface. It requires listener migration inside a
The subtlety comes after the obvious fix. The CVE text notes that once
That is why the patch wraps post-queue-add dereferences of the new listener in RCU read-side protection. Linux listeners are freed using
This is where kernel networking earns its reputation for being both elegant and terrifying. The user-visible symptom is a sleeping event loop. The kernel-side correction has to respect refcount transfer, request-socket ownership, listener shutdown, RCU lifetime rules, and the difference between established children and half-open requests.
For defenders, the question is less “what number did NVD assign?” and more “can this bug cause service degradation in my environment?” If the answer involves Linux servers using
The likely impact is denial-of-service-like behavior in specific conditions: not necessarily a system-wide crash, but a readiness failure that can leave accept waiters asleep. In busy services, a later connection may generate another wakeup and mask the issue. In quieter services, test environments, or edge deployments, the stall may be more visible.
That intermittent nature can be worse than a clean failure. A clean failure triggers alarms. A rare accept wakeup miss becomes folklore: “sometimes reloads hang,” “sometimes one worker stops taking traffic,” or “sometimes epoll misses something after restart.”
Windows-heavy shops routinely run Linux in WSL, Hyper-V guests, Azure VMs, containers, appliances, network tools, CI runners, and security products. Developers build and test Linux services on Windows workstations. Enterprises deploy Linux-based proxies, observability agents, and service infrastructure next to Windows fleets. The operational perimeter is hybrid whether procurement calls it that or not.
For WSL users, the practical risk depends on the kernel build Microsoft ships and whether the workload actually uses the affected networking pattern. For production Linux VMs and containers, the more relevant question is the host and guest kernel lineage. Containers share the host kernel, so patching an image alone does not fix a kernel TCP bug in the underlying node.
That distinction still trips up otherwise mature teams. A container rebuild can update OpenSSL, glibc, Python, or Nginx packages inside the filesystem. It cannot patch the host kernel that implements TCP listener migration. If a Kubernetes node, VM host, or bare-metal server is running an affected kernel, the fix has to land there.
CVE-2026-46015 sits at the intersection of all three.
A traditional single-process server using a straightforward blocking accept loop on a single listener may never exercise this path. A modern service with multiple workers bound to the same port, rolling process replacement, and epoll-driven event loops is much more interesting. That is also the kind of service likely to sit on an important path: a proxy tier, an ingress component, a storage gateway, or a custom internal platform daemon.
This does not mean every such service is exploitable from the internet in a simple way. The public record does not establish a weaponized attack path, and the trigger depends on timing and listener lifecycle behavior. But attackers do not always need perfect exploitability to create pain. If a remote client can influence connection timing around restarts or worker churn, availability effects become plausible enough to take seriously.
That testing angle matters. Kernel bugs like this are not always prevented by eyeballing the code because the failure is a violated contract across subsystems. The accept queue receives an entry; the event waiter sleeps; the listener lifecycle changes; the observable break appears only when those pieces align.
By adding explicit readiness checks, the kernel community turns a race-prone behavioral assumption into something that can be tested. That is how mature infrastructure improves: not by declaring the TCP stack “done,” but by encoding the weird cases that production eventually finds.
The CVE text also explains why a related request-timer path does not need the same change. Half-open requests become readable only after the final ACK, where existing TCP child processing already wakes the listener. Once the request is visible through the established hash insertion path, the success path no longer touches the new listener directly. That level of specificity is useful because it narrows the fix to the path that actually violates readiness semantics.
The remediation path is kernel-focused. Track your distribution’s kernel advisories, stable kernel updates, cloud image refreshes, and managed node patch channels. For self-managed systems, confirm the running kernel after reboot, not merely the installed package version. Linux makes it easy to install a fixed kernel and then keep running the old one until the next maintenance window.
Cloud and virtualization layers add another wrinkle. A guest kernel bug needs a guest kernel update, but appliances and managed platforms may abstract that away. Container hosts, Kubernetes nodes, and edge devices deserve special scrutiny because they often run long-lived kernels while user-space images update frequently.
The safest operational posture is boring: patch to a vendor kernel that includes the fix, reboot into it, and verify the running version. If reboot timing is difficult, prioritize systems that combine external TCP exposure,
Its real-world cost may be diagnostic time. Intermittent stalls in readiness-driven servers are hard to reproduce, especially when the workaround appears to be “another connection arrived and everything woke up.” That makes the bug a candidate for disappearing under load tests and reappearing during low-traffic maintenance windows.
Event-loop bugs also have a habit of implicating innocent code. Developers may instrument epoll, blame edge-triggered behavior, add redundant wakeups, or alter worker restart logic. Operations teams may tune backlog sizes or load balancer health checks. All of those can change the symptoms without fixing the kernel condition.
That is why the CVE is worth covering even before NVD assigns a score. A vulnerability record can be a security artifact, but it can also be an operational breadcrumb. When the symptom is “accept waiters can remain asleep indefinitely,” anyone responsible for Linux network services should file it under both security and reliability.
The Kernel Bug Is Small; the Contract It Breaks Is Not
At the center of CVE-2026-46015 is a deceptively ordinary promise. When a listening TCP socket has a connection ready to accept, software waiting on that listener should be told. That notification is the difference between a service that drains its accept queue and one that sits idle while work is already waiting in the kernel.The flaw appears when Linux migrates an established child socket from a closing listener to another listener in the same
SO_REUSEPORT group. The target listener receives the accept-queue entry, meaning the connection is there. But the code path failed to call the listener’s readiness callback, so processes waiting in poll(), epoll_wait(), or blocking accept() could keep sleeping indefinitely.That distinction matters because nonblocking
accept() still works. Code that repeatedly checks the accept queue directly can discover the migrated connection. Code that relies on readiness notification — which is the normal design for scalable network servers — can miss it until some later event wakes the listener.In other words, the bug is not that Linux loses the connection. It is that Linux can fail to ring the bell.
SO_REUSEPORT Turned Socket Binding Into a Load-Balancing Primitive
SO_REUSEPORT is one of those kernel features that sounds like a convenience knob until you see how deeply it is baked into modern server design. It allows multiple sockets to bind to the same address and port, letting a multi-process or multi-threaded service distribute incoming connections across workers without a user-space accept lock becoming the bottleneck.That makes it attractive to web servers, proxies, RPC frameworks, service meshes, container platforms, and custom high-throughput daemons. It also helps with rolling restarts and worker replacement: one listener can close while others remain active, and the kernel can keep the port alive across process churn.
The migration behavior involved in this CVE is part of that more ambitious world. When a listener is closing, the kernel may migrate queued or partially processed connection state to another listener in the same reuseport group. That is the kind of feature administrators love because it turns process death or restart into a survivable event.
But the more the kernel hides lifecycle complexity from user space, the more important the exact notification semantics become. A migrated connection is only useful if the application knows it should wake up and accept it. CVE-2026-46015 is a reminder that load-balancing primitives are also correctness primitives.
The Failure Mode Looks Like a Hung Service, Not a Broken Kernel
The unnerving part of this bug is that it may not look like a vulnerability in the usual sense. There is no obvious memory smash in the public description. There is no advertised privilege escalation. There is no NVD severity score yet to tell scanners how loudly to shout.Instead, the failure mode is operationally familiar: a listener appears healthy, the port remains open, some connections continue to work, and yet a worker or process waiting on readiness may never wake for a migrated accept entry. Depending on the service architecture, that could present as intermittent hangs, uneven load distribution, slow drains during reloads, or connections that appear to stall after a restart event.
That makes triage harder. A sysadmin may blame the application. A developer may blame an event-loop edge case. An SRE may suspect a proxy, a firewall, a Kubernetes readiness probe, or an unlucky race in deployment automation. The actual culprit sits lower: the kernel placed work on the target listener’s accept queue without performing the wakeup that readiness-driven software expects.
The bug also has a narrow trigger surface. It requires listener migration inside a
SO_REUSEPORT group, not ordinary one-process TCP listening. But “narrow” is not the same as “irrelevant.” The affected pattern is common precisely among software that cares about uptime, scaling, and graceful replacement.The Fix Says More Than the CVE Score Ever Will
The core fix is straightforward: after successful migration ininet_csk_listen_stop(), call sk_data_ready() on the new listener. That callback is the kernel’s way of notifying waiting code that data — in this case, an accept-ready connection — is available.The subtlety comes after the obvious fix. The CVE text notes that once
inet_csk_reqsk_queue_add() succeeds, the reference acquired during reuseport migration is effectively transferred to the request’s listener field. Another CPU may then dequeue the request via accept() or tear down the listener and drop that listener reference.That is why the patch wraps post-queue-add dereferences of the new listener in RCU read-side protection. Linux listeners are freed using
SOCK_RCU_FREE, so the fix is not merely “call the missing callback.” It also has to ensure that the code does not race with another CPU freeing the listener while the notification path is still looking at it.This is where kernel networking earns its reputation for being both elegant and terrifying. The user-visible symptom is a sleeping event loop. The kernel-side correction has to respect refcount transfer, request-socket ownership, listener shutdown, RCU lifetime rules, and the difference between established children and half-open requests.
This Is Availability Risk, Even Without a CVSS Number
NVD’s entry for CVE-2026-46015 was still awaiting enrichment when published, with no CVSS 4.0, 3.x, or 2.0 score assigned by NIST. That absence should not be misread as a declaration of safety. It means the public vulnerability record had not yet been fully scored.For defenders, the question is less “what number did NVD assign?” and more “can this bug cause service degradation in my environment?” If the answer involves Linux servers using
SO_REUSEPORT, event-driven accept loops, and graceful listener shutdown or migration, the bug deserves attention.The likely impact is denial-of-service-like behavior in specific conditions: not necessarily a system-wide crash, but a readiness failure that can leave accept waiters asleep. In busy services, a later connection may generate another wakeup and mask the issue. In quieter services, test environments, or edge deployments, the stall may be more visible.
That intermittent nature can be worse than a clean failure. A clean failure triggers alarms. A rare accept wakeup miss becomes folklore: “sometimes reloads hang,” “sometimes one worker stops taking traffic,” or “sometimes epoll misses something after restart.”
Windows Administrators Still Have a Linux Kernel Problem
This is WindowsForum.com, so it is worth stating plainly: this is not a Windows kernel CVE. It is a Linux kernel TCP vulnerability. But in 2026, that boundary is less comforting than it once was.Windows-heavy shops routinely run Linux in WSL, Hyper-V guests, Azure VMs, containers, appliances, network tools, CI runners, and security products. Developers build and test Linux services on Windows workstations. Enterprises deploy Linux-based proxies, observability agents, and service infrastructure next to Windows fleets. The operational perimeter is hybrid whether procurement calls it that or not.
For WSL users, the practical risk depends on the kernel build Microsoft ships and whether the workload actually uses the affected networking pattern. For production Linux VMs and containers, the more relevant question is the host and guest kernel lineage. Containers share the host kernel, so patching an image alone does not fix a kernel TCP bug in the underlying node.
That distinction still trips up otherwise mature teams. A container rebuild can update OpenSSL, glibc, Python, or Nginx packages inside the filesystem. It cannot patch the host kernel that implements TCP listener migration. If a Kubernetes node, VM host, or bare-metal server is running an affected kernel, the fix has to land there.
The Most Exposed Software Is the Software Designed Not to Go Down
The irony of this CVE is that it is most relevant to designs built for resilience.SO_REUSEPORT is often used to make servers scale better and restart more gracefully. Listener migration exists to avoid dropping work when a listener closes. Event-driven readiness APIs exist so services can handle large numbers of connections efficiently.CVE-2026-46015 sits at the intersection of all three.
A traditional single-process server using a straightforward blocking accept loop on a single listener may never exercise this path. A modern service with multiple workers bound to the same port, rolling process replacement, and epoll-driven event loops is much more interesting. That is also the kind of service likely to sit on an important path: a proxy tier, an ingress component, a storage gateway, or a custom internal platform daemon.
This does not mean every such service is exploitable from the internet in a simple way. The public record does not establish a weaponized attack path, and the trigger depends on timing and listener lifecycle behavior. But attackers do not always need perfect exploitability to create pain. If a remote client can influence connection timing around restarts or worker churn, availability effects become plausible enough to take seriously.
The Patch Trail Shows the Kernel Community Treating It as Correctness Debt
The upstream discussion around the fix framed the bug as a missing wakeup after reuseport migration. The patch series also extended kernel self-tests to check epoll readiness around migration, including cases where a listener should become ready immediately after shutdown-triggered migration.That testing angle matters. Kernel bugs like this are not always prevented by eyeballing the code because the failure is a violated contract across subsystems. The accept queue receives an entry; the event waiter sleeps; the listener lifecycle changes; the observable break appears only when those pieces align.
By adding explicit readiness checks, the kernel community turns a race-prone behavioral assumption into something that can be tested. That is how mature infrastructure improves: not by declaring the TCP stack “done,” but by encoding the weird cases that production eventually finds.
The CVE text also explains why a related request-timer path does not need the same change. Half-open requests become readable only after the final ACK, where existing TCP child processing already wakes the listener. Once the request is visible through the established hash insertion path, the success path no longer touches the new listener directly. That level of specificity is useful because it narrows the fix to the path that actually violates readiness semantics.
Patching Should Follow the Kernel, Not the Package Name
Administrators should resist the urge to treat CVE-2026-46015 as an application vulnerability. Updating a web server package may be good hygiene, but it is not the relevant fix unless the vendor bundles and boots a patched kernel as part of an appliance update.The remediation path is kernel-focused. Track your distribution’s kernel advisories, stable kernel updates, cloud image refreshes, and managed node patch channels. For self-managed systems, confirm the running kernel after reboot, not merely the installed package version. Linux makes it easy to install a fixed kernel and then keep running the old one until the next maintenance window.
Cloud and virtualization layers add another wrinkle. A guest kernel bug needs a guest kernel update, but appliances and managed platforms may abstract that away. Container hosts, Kubernetes nodes, and edge devices deserve special scrutiny because they often run long-lived kernels while user-space images update frequently.
The safest operational posture is boring: patch to a vendor kernel that includes the fix, reboot into it, and verify the running version. If reboot timing is difficult, prioritize systems that combine external TCP exposure,
SO_REUSEPORT-using services, and graceful restart or worker migration behavior.The Quiet Bugs Are the Ones That Waste Weekends
Security teams tend to sort vulnerabilities into familiar buckets: remote code execution, privilege escalation, information disclosure, denial of service. CVE-2026-46015 does not fit neatly into the first three based on the public description, and even the denial-of-service label can feel too blunt.Its real-world cost may be diagnostic time. Intermittent stalls in readiness-driven servers are hard to reproduce, especially when the workaround appears to be “another connection arrived and everything woke up.” That makes the bug a candidate for disappearing under load tests and reappearing during low-traffic maintenance windows.
Event-loop bugs also have a habit of implicating innocent code. Developers may instrument epoll, blame edge-triggered behavior, add redundant wakeups, or alter worker restart logic. Operations teams may tune backlog sizes or load balancer health checks. All of those can change the symptoms without fixing the kernel condition.
That is why the CVE is worth covering even before NVD assigns a score. A vulnerability record can be a security artifact, but it can also be an operational breadcrumb. When the symptom is “accept waiters can remain asleep indefinitely,” anyone responsible for Linux network services should file it under both security and reliability.
The Practical Read on CVE-2026-46015
The immediate story is not panic; it is prioritization. CVE-2026-46015 is a kernel TCP correctness bug with potential availability consequences in a specific but important class of network services. Treat it as a patching item for Linux systems that use modern listener scaling and restart patterns, including those living inside otherwise Windows-centered estates.- CVE-2026-46015 affects the Linux kernel TCP path for listener migration within
SO_REUSEPORTgroups. - The bug can leave
poll(),epoll_wait(), and blockingaccept()waiters asleep even after a migrated connection reaches the target listener’s accept queue. - Nonblocking
accept()can still work because it checks the queue directly, which may make the defect intermittent and hard to diagnose. - NVD published the CVE on May 27, 2026, but had not assigned a NIST CVSS score at the time of the record described here.
- The fix calls the target listener’s readiness callback after successful migration and protects later listener dereferences with RCU read-side locking.
- Containers do not carry their own Linux kernel, so containerized workloads depend on the host kernel being patched.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:10:59-07:00
NVD - CVE-2026-46015
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:10:59-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: mail-archive.com
[PATCH net v2 1/2] tcp: call sk_data_ready() after listener migration
www.mail-archive.com
- Related coverage: korg.docs.kernel.org
- Related coverage: codebrowser.dev
inet_connection_sock.c source code [linux/net/ipv4/inet_connection_sock.c] - Codebrowser
Source code of linux/net/ipv4/inet_connection_sock.c linux v6.19-r on KDAB Codebrowser
codebrowser.dev
- Related coverage: kernel.googlesource.com
- Related coverage: lpc.events
- Related coverage: ftpmirror.infania.net
- Related coverage: docs.redhat.com
