Kernel.org assigned CVE-2026-46086 on May 27, 2026, to a Linux bridge forwarding database race in which concurrent local FDB updates can let RCU readers dereference a stale or NULL destination pointer. The bug is not a remote-code-execution thunderclap, and the National Vulnerability Database had not yet supplied a CVSS score when the record appeared. But it is exactly the sort of kernel plumbing flaw that matters in 2026: small, concurrent, hard to see in testing, and sitting beneath containers, virtual switches, routers, lab hosts, and Linux-backed infrastructure that Windows administrators increasingly depend on. The fix is only a few lines of defensive pointer handling, yet the lesson is broader than the patch.
CVE-2026-46086 lives in the Linux bridge code, the part of the kernel that lets a Linux system behave like an Ethernet switch. That code is not exotic. It is used in virtualization hosts, container networks, software routers, embedded appliances, developer workstations, and cloud images where Linux quietly moves packets between interfaces, namespaces, VLANs, and virtual machines.
The vulnerable area is the bridge forwarding database, or FDB, which maps MAC addresses to bridge ports. In normal operation, entries can be read by one part of the kernel while another path updates them. Linux uses RCU, or read-copy-update, to make this kind of lockless read-side access fast and safe when the rules are followed carefully.
The failure here was not that the kernel forgot to check for NULL. It was subtler: readers could check
That creates the classic race window that kernel developers lose sleep over. A reader sees a valid pointer, proceeds past the guard, and then a second load observes NULL before
Still, dismissing the bug as “just a crash” would be a mistake. A bridge crash can take down more than one workload. On a virtualization server, it can interrupt guest networking or panic the host. On a container platform, it can disrupt multiple tenants or services. On a small office firewall or lab router, it may be the whole network path.
The local nature of the trigger also narrows the risk. This is not, based on the public description, a drive-by packet from the Internet that knocks over any Linux bridge. The race involves local FDB manipulation and sysfs reading paths, so the most plausible concern is a local user, container, management process, or privileged network component that can exercise the affected code paths.
That does not make it irrelevant to WindowsForum readers. Windows shops increasingly run Linux in the places where networking decisions are made: WSL development boxes, Hyper-V guests, Kubernetes nodes, Proxmox labs, NAS appliances, VPN gateways, and security tools. Kernel vulnerabilities do not care whether the person on call thinks of the environment as “a Windows network.”
That is not a cosmetic cleanup. In lockless kernel code, repeated plain loads are invitations for inconsistency. The compiler and CPU are allowed more freedom than most application developers intuitively expect, and concurrent updates can make two reads of the “same” field tell different stories.
The bridge code had multiple readers that looked at
The corrected pattern is the one kernel maintainers reach for in this class of bug: capture the pointer once, test it once, use the captured value consistently. It is not dramatic, but it is exactly how mature kernel engineering reduces the number of places where a race can hide.
That history matters because old infrastructure accumulates new callers. Code paths that once served straightforward host networking now sit under orchestration systems, virtualization stacks, and network automation. A sysfs read that looked harmless in a simpler era can become reachable through monitoring agents, inventory collectors, or troubleshooting scripts.
The bug also highlights the awkward middle age of Linux networking interfaces. Newer tooling often uses netlink, but older sysfs paths remain because compatibility has a long half-life. The vulnerable
For administrators, that is the uncomfortable part. You do not have to knowingly use an obscure interface for it to matter. A management agent, backup appliance, security scanner, or “temporary” script written five years ago may be poking at exactly the sort of compatibility surface that kernel developers must keep alive.
CVE-2026-46086 is a good example of that almost-correct zone. The FDB entry itself remained alive, so this was not the simplest form of use-after-free. The unstable part was a field inside the entry. The object survived, but one of its meaningful relationships changed while readers were still making decisions from it.
That is why the fix uses a stable snapshot rather than a giant lock. Locking the whole path would likely be heavier and less appropriate for a hot networking code path. The aim is not to serialize everything; it is to make each reader operate on a coherent view of the pointer it needs.
For readers who do not live in kernel code, the practical takeaway is simple: concurrency bugs are rarely visible from the feature list. A network bridge can appear stable for months, then fall over when a rare update pattern collides with a read path at just the wrong time. That is why small stable patches matter.
The absence of a score is not a verdict. It means the record is still young. Administrators should resist both temptations: do not inflate the bug into an emergency without evidence, and do not ignore it because the familiar red severity badge has not appeared yet.
A reasonable early reading is that this is a local denial-of-service issue affecting systems with the vulnerable bridge code and reachable trigger conditions. The strongest risk sits on multi-user systems, container hosts, lab hypervisors, network appliances, and any environment where less-trusted code can influence bridge state or hammer management interfaces.
The operational decision is therefore less about CVSS theater and more about exposure. If a Linux system is a single-user desktop with no bridge configured, this CVE is unlikely to be your top concern. If it is a host that bridges traffic for other systems, a crash can be an outage even without data theft.
This is where Linux security often becomes less tidy than Windows servicing. Microsoft ships cumulative updates for a defined product matrix. Linux users inherit a mix of upstream stable branches, vendor kernels, enterprise backports, cloud-provider images, and appliance firmware. The same CVE may be fixed by an obviously newer kernel in one environment and by a quiet backport in another.
That difference can confuse scanners. A vulnerability scanner may see a kernel version that looks old and flag it, even if the distribution has backported the patch. Conversely, an appliance may run a vendor-custom kernel whose public version string tells you very little about whether this exact bridge fix is present.
The only reliable answer is vendor confirmation or patch inspection. On conventional Linux distributions, administrators should look for kernel updates published after the upstream stable fix and check the distribution’s CVE tracker or changelog. On appliances, they should look for firmware release notes and ask vendors directly when notes are vague.
The direct WSL angle is probably limited. WSL 2 uses a Microsoft-supplied Linux kernel in a lightweight VM, and typical WSL networking does not resemble a production Linux bridge host configured by an administrator. But Windows developers who run Docker Desktop, Kubernetes-in-VM setups, nested labs, or custom bridging should still understand that their “local dev” network stack can contain real kernel attack surface.
The more important Windows-adjacent concern is the infrastructure around Windows. A Windows-heavy business may rely on a Linux firewall, a Proxmox cluster, a NAS with bridge features, or a container host that supports internal applications. If that box crashes, users do not care that Active Directory itself remained pristine.
For forum readers, the lesson is practical: inventory the Linux you actually depend on, not the Linux you admit to owning. The bridge that matters may be inside a box labeled storage, backup, IoT gateway, SD-WAN, monitoring, or “temporary lab host.”
Whether CVE-2026-46086 is reachable from a particular container depends on capabilities, namespace configuration, bridge setup, sysfs exposure, and host policy. A tightly confined container with no network administration rights and no useful sysfs access is a different risk from a privileged container running network tooling. But in real environments, privileged containers exist, especially in CI systems, lab clusters, and network-function deployments.
That is why denial-of-service bugs in shared kernels deserve attention. Containers do not give each workload its own kernel. If one workload can trigger a kernel crash, the blast radius can include every other workload on that node.
This is also a reminder that “least privilege” for containers is not paperwork. Dropping unnecessary capabilities, avoiding privileged containers, limiting host filesystem mounts, and controlling access to sysfs are meaningful mitigations when kernel bugs like this appear. They may not be as satisfying as a patch, but they reduce the number of paths an attacker or faulty process can use to reach fragile code.
A race condition becomes more plausible when automation creates repeated timing opportunities. A human occasionally running a command is one thing. A fleet agent polling forwarding tables every few seconds across hosts during interface churn is another.
This does not mean monitoring is dangerous. It means monitoring interacts with kernel surfaces, and those surfaces need the same patch discipline as packet handling. A bug triggered by reading state is still a production bug if your tooling reads that state continuously.
Administrators should therefore think about this CVE not only in terms of malicious triggering but also accidental triggering. Network reconfiguration, bridge port changes, MAC address movement, and concurrent polling are exactly the sort of mundane operations that can expose races without an attacker being present.
This is not the sort of patch that changes architecture diagrams. It does not add a new mitigation framework or redesign bridge FDB handling. It takes a field that was being treated as if it were stable across a sequence and forces the code to use a stable local snapshot instead.
The modest size of the change should not make it seem optional. Kernel security fixes are often like this: small diffs with large reliability implications. A crash bug can be fixed by replacing repeated assumptions with one carefully preserved fact.
For IT teams that build custom kernels, the patch is also easy to reason about. It touches bridge readers and the local FDB update path. If you maintain an out-of-tree kernel or vendor tree, this is the sort of fix you want merged cleanly rather than reimplemented from memory.
The second question is whether local users or workloads are trusted. On single-purpose appliances, local access may be tightly controlled. On shared development servers or CI runners, it may not be. On container hosts, “local” might include workloads supplied by teams that should not be able to crash the node.
The third question is whether your vendor has shipped the fix. Upstream stable commits are important, but most administrators should not cherry-pick into production kernels unless they already operate at that level. The safer path is to consume the distribution or appliance update that includes the backport, then reboot or live-patch according to the vendor’s support model.
Finally, confirm that the new kernel is actually running. Linux patching still has a very human failure mode: the package installs, the reboot is deferred, and the vulnerable kernel remains in memory for weeks. For a kernel networking bug, “installed but not booted” is not a mitigation.
But concentrated risk is still risk. A bridge host is often a concentration point by design. It connects guests, containers, VLANs, or physical networks. If that host panics, the outage is larger than the affected code path sounds.
Security teams should therefore avoid ranking it by name recognition. This is not OpenSSL, Exchange, or a browser zero-day. It is a Linux kernel bridge race. In the wrong place, that is enough to matter.
The right response is disciplined rather than dramatic: identify bridge-bearing systems, check vendor kernel status, prioritize shared or exposed hosts, reduce unnecessary local access to network administration paths, and schedule the kernel update with the seriousness you would give any infrastructure crash fix.
A Small Bridge Bug Lands in a Very Large Attack Surface
CVE-2026-46086 lives in the Linux bridge code, the part of the kernel that lets a Linux system behave like an Ethernet switch. That code is not exotic. It is used in virtualization hosts, container networks, software routers, embedded appliances, developer workstations, and cloud images where Linux quietly moves packets between interfaces, namespaces, VLANs, and virtual machines.The vulnerable area is the bridge forwarding database, or FDB, which maps MAC addresses to bridge ports. In normal operation, entries can be read by one part of the kernel while another path updates them. Linux uses RCU, or read-copy-update, to make this kind of lockless read-side access fast and safe when the rules are followed carefully.
The failure here was not that the kernel forgot to check for NULL. It was subtler: readers could check
f->dst, then later dereference f->dst again, assuming the value had remained the same. Meanwhile, fdb_delete_local() could rewrite that same destination pointer in place, moving it to another port or setting it to NULL while keeping the FDB entry itself alive.That creates the classic race window that kernel developers lose sleep over. A reader sees a valid pointer, proceeds past the guard, and then a second load observes NULL before
port_no is read. The outcome described in the CVE is a NULL pointer dereference through the brforward_read() sysfs path, which means a local operation can crash the kernel under the right timing.This Is a Denial-of-Service Bug, Not a Hollywood Exploit
The available record points to a NULL pointer dereference, which usually means denial of service rather than privilege escalation. That distinction matters. A kernel crash is serious on a host carrying production traffic, but it is not the same as an attacker gaining root or breaking out of a virtual machine.Still, dismissing the bug as “just a crash” would be a mistake. A bridge crash can take down more than one workload. On a virtualization server, it can interrupt guest networking or panic the host. On a container platform, it can disrupt multiple tenants or services. On a small office firewall or lab router, it may be the whole network path.
The local nature of the trigger also narrows the risk. This is not, based on the public description, a drive-by packet from the Internet that knocks over any Linux bridge. The race involves local FDB manipulation and sysfs reading paths, so the most plausible concern is a local user, container, management process, or privileged network component that can exercise the affected code paths.
That does not make it irrelevant to WindowsForum readers. Windows shops increasingly run Linux in the places where networking decisions are made: WSL development boxes, Hyper-V guests, Kubernetes nodes, Proxmox labs, NAS appliances, VPN gateways, and security tools. Kernel vulnerabilities do not care whether the person on call thinks of the environment as “a Windows network.”
The Patch Says More Than the CVE Record
The fix is refreshingly direct. Instead of loadingf->dst repeatedly, affected RCU readers take a single snapshot with READ_ONCE() and use that snapshot for the rest of the access sequence. The writer side then updates f->dst with WRITE_ONCE() so both sides agree on the access pattern.That is not a cosmetic cleanup. In lockless kernel code, repeated plain loads are invitations for inconsistency. The compiler and CPU are allowed more freedom than most application developers intuitively expect, and concurrent updates can make two reads of the “same” field tell different stories.
The bridge code had multiple readers that looked at
f->dst, including the path that fills forwarding database information for the old sysfs brforward interface. The most obvious crash path was in br_fdb_fillbuf(), where the code ignored entries with no destination, then later read the destination’s port number. A concurrent update could invalidate the assumption between those two moments.The corrected pattern is the one kernel maintainers reach for in this class of bug: capture the pointer once, test it once, use the captured value consistently. It is not dramatic, but it is exactly how mature kernel engineering reduces the number of places where a race can hide.
The Bridge Is Old Infrastructure With New Responsibilities
Linux bridge began as a practical way to connect interfaces at Layer 2. Over time, that boring utility became a foundation for virtualized computing. A Linux host may bridge a physical NIC to virtual NICs, connect containers through veth pairs, carry tagged VLANs, proxy neighbor discovery, and export forwarding information to user space tools.That history matters because old infrastructure accumulates new callers. Code paths that once served straightforward host networking now sit under orchestration systems, virtualization stacks, and network automation. A sysfs read that looked harmless in a simpler era can become reachable through monitoring agents, inventory collectors, or troubleshooting scripts.
The bug also highlights the awkward middle age of Linux networking interfaces. Newer tooling often uses netlink, but older sysfs paths remain because compatibility has a long half-life. The vulnerable
brforward_read() path is part of that long tail: unglamorous, still present, and potentially exercised by software that nobody has audited in years.For administrators, that is the uncomfortable part. You do not have to knowingly use an obscure interface for it to matter. A management agent, backup appliance, security scanner, or “temporary” script written five years ago may be poking at exactly the sort of compatibility surface that kernel developers must keep alive.
RCU Bugs Are Where Confidence Goes to Die
RCU is one of Linux’s great performance tools. It lets readers move quickly without taking heavy locks, while writers arrange updates so old objects remain safe until readers have moved on. When used correctly, it is elegant. When used almost correctly, it can produce failures that appear only under precise timing.CVE-2026-46086 is a good example of that almost-correct zone. The FDB entry itself remained alive, so this was not the simplest form of use-after-free. The unstable part was a field inside the entry. The object survived, but one of its meaningful relationships changed while readers were still making decisions from it.
That is why the fix uses a stable snapshot rather than a giant lock. Locking the whole path would likely be heavier and less appropriate for a hot networking code path. The aim is not to serialize everything; it is to make each reader operate on a coherent view of the pointer it needs.
For readers who do not live in kernel code, the practical takeaway is simple: concurrency bugs are rarely visible from the feature list. A network bridge can appear stable for months, then fall over when a rare update pattern collides with a read path at just the wrong time. That is why small stable patches matter.
The Missing CVSS Score Should Not Be Mistaken for Missing Risk
At publication time, the NVD entry was marked as awaiting enrichment, with no NIST CVSS 4.0, 3.x, or 2.0 score assigned. That is common for fresh Linux kernel CVEs, especially now that kernel.org-originated CVE records often appear before the broader vulnerability ecosystem has attached scoring, affected-product tables, and vendor advisories.The absence of a score is not a verdict. It means the record is still young. Administrators should resist both temptations: do not inflate the bug into an emergency without evidence, and do not ignore it because the familiar red severity badge has not appeared yet.
A reasonable early reading is that this is a local denial-of-service issue affecting systems with the vulnerable bridge code and reachable trigger conditions. The strongest risk sits on multi-user systems, container hosts, lab hypervisors, network appliances, and any environment where less-trusted code can influence bridge state or hammer management interfaces.
The operational decision is therefore less about CVSS theater and more about exposure. If a Linux system is a single-user desktop with no bridge configured, this CVE is unlikely to be your top concern. If it is a host that bridges traffic for other systems, a crash can be an outage even without data theft.
Stable Backports Are the Real Security Boundary
The CVE record lists multiple stable kernel commits, which tells us this fix is being carried into maintained kernel branches rather than left only for mainline. That is the part administrators should watch. For most organizations, “patched” does not mean “the upstream commit exists.” It means the fix has landed in the kernel package supplied by Ubuntu, Debian, Red Hat, SUSE, Arch, Proxmox, Android-derived vendors, NAS makers, firewall projects, or whatever distribution owns the running image.This is where Linux security often becomes less tidy than Windows servicing. Microsoft ships cumulative updates for a defined product matrix. Linux users inherit a mix of upstream stable branches, vendor kernels, enterprise backports, cloud-provider images, and appliance firmware. The same CVE may be fixed by an obviously newer kernel in one environment and by a quiet backport in another.
That difference can confuse scanners. A vulnerability scanner may see a kernel version that looks old and flag it, even if the distribution has backported the patch. Conversely, an appliance may run a vendor-custom kernel whose public version string tells you very little about whether this exact bridge fix is present.
The only reliable answer is vendor confirmation or patch inspection. On conventional Linux distributions, administrators should look for kernel updates published after the upstream stable fix and check the distribution’s CVE tracker or changelog. On appliances, they should look for firmware release notes and ask vendors directly when notes are vague.
Windows Administrators Are in This Story Too
It is easy to file this under “Linux people problems,” but that boundary has not matched reality for years. Windows administrators routinely manage Linux infrastructure, whether formally or accidentally. Hyper-V hosts run Linux guests. Developers use WSL. Azure and on-prem estates mix Windows Server with Linux appliances. Security teams deploy Linux-based sensors into Windows networks.The direct WSL angle is probably limited. WSL 2 uses a Microsoft-supplied Linux kernel in a lightweight VM, and typical WSL networking does not resemble a production Linux bridge host configured by an administrator. But Windows developers who run Docker Desktop, Kubernetes-in-VM setups, nested labs, or custom bridging should still understand that their “local dev” network stack can contain real kernel attack surface.
The more important Windows-adjacent concern is the infrastructure around Windows. A Windows-heavy business may rely on a Linux firewall, a Proxmox cluster, a NAS with bridge features, or a container host that supports internal applications. If that box crashes, users do not care that Active Directory itself remained pristine.
For forum readers, the lesson is practical: inventory the Linux you actually depend on, not the Linux you admit to owning. The bridge that matters may be inside a box labeled storage, backup, IoT gateway, SD-WAN, monitoring, or “temporary lab host.”
Containers Make Local Bugs Feel Less Local
The CVE description points to local kernel interactions, and local kernel bugs have always been graded differently from remote ones. Containers complicate that model. A process inside a container is local to the kernel even if the tenant, workload, or application owner is not trusted in the same way as a shell user on the host.Whether CVE-2026-46086 is reachable from a particular container depends on capabilities, namespace configuration, bridge setup, sysfs exposure, and host policy. A tightly confined container with no network administration rights and no useful sysfs access is a different risk from a privileged container running network tooling. But in real environments, privileged containers exist, especially in CI systems, lab clusters, and network-function deployments.
That is why denial-of-service bugs in shared kernels deserve attention. Containers do not give each workload its own kernel. If one workload can trigger a kernel crash, the blast radius can include every other workload on that node.
This is also a reminder that “least privilege” for containers is not paperwork. Dropping unnecessary capabilities, avoiding privileged containers, limiting host filesystem mounts, and controlling access to sysfs are meaningful mitigations when kernel bugs like this appear. They may not be as satisfying as a patch, but they reduce the number of paths an attacker or faulty process can use to reach fragile code.
The Sysfs Angle Is a Warning About Observability Tools
One of the affected paths is a sysfs read path that fills bridge forwarding information. That should catch the attention of anyone running monitoring and asset discovery tooling. Observability agents often read kernel-exposed state at high frequency, and they may do so precisely when the network is changing.A race condition becomes more plausible when automation creates repeated timing opportunities. A human occasionally running a command is one thing. A fleet agent polling forwarding tables every few seconds across hosts during interface churn is another.
This does not mean monitoring is dangerous. It means monitoring interacts with kernel surfaces, and those surfaces need the same patch discipline as packet handling. A bug triggered by reading state is still a production bug if your tooling reads that state continuously.
Administrators should therefore think about this CVE not only in terms of malicious triggering but also accidental triggering. Network reconfiguration, bridge port changes, MAC address movement, and concurrent polling are exactly the sort of mundane operations that can expose races without an attacker being present.
The Fix Is Tiny Because the Contract Was Tiny
The elegance of the patch is that it restores a contract: once a reader decides what destination pointer it is using, it does not quietly ask the same unstable field again.READ_ONCE() tells the compiler to perform a single access as written, while WRITE_ONCE() makes the writer side explicit. That pairing matters in code where memory ordering, compiler behavior, and concurrent mutation all intersect.This is not the sort of patch that changes architecture diagrams. It does not add a new mitigation framework or redesign bridge FDB handling. It takes a field that was being treated as if it were stable across a sequence and forces the code to use a stable local snapshot instead.
The modest size of the change should not make it seem optional. Kernel security fixes are often like this: small diffs with large reliability implications. A crash bug can be fixed by replacing repeated assumptions with one carefully preserved fact.
For IT teams that build custom kernels, the patch is also easy to reason about. It touches bridge readers and the local FDB update path. If you maintain an out-of-tree kernel or vendor tree, this is the sort of fix you want merged cleanly rather than reimplemented from memory.
Patch Management Has to Follow the Packet Path
The first operational question is whether you run affected bridge code in a meaningful role. A desktop with no bridge devices is not the same as a virtualization node. A router, firewall, Kubernetes worker, Proxmox host, Open vSwitch-adjacent deployment using Linux bridge components, or network appliance deserves more urgent attention.The second question is whether local users or workloads are trusted. On single-purpose appliances, local access may be tightly controlled. On shared development servers or CI runners, it may not be. On container hosts, “local” might include workloads supplied by teams that should not be able to crash the node.
The third question is whether your vendor has shipped the fix. Upstream stable commits are important, but most administrators should not cherry-pick into production kernels unless they already operate at that level. The safer path is to consume the distribution or appliance update that includes the backport, then reboot or live-patch according to the vendor’s support model.
Finally, confirm that the new kernel is actually running. Linux patching still has a very human failure mode: the package installs, the reboot is deferred, and the vulnerable kernel remains in memory for weeks. For a kernel networking bug, “installed but not booted” is not a mitigation.
The Practical Risk Is Concentrated, Not Universal
CVE-2026-46086 is unlikely to be the vulnerability that dominates executive dashboards. It has no NVD score yet, no public indication of remote exploitation in the provided record, and no obvious path to privilege escalation from the description alone. It is a kernel crash bug in a specific concurrency scenario.But concentrated risk is still risk. A bridge host is often a concentration point by design. It connects guests, containers, VLANs, or physical networks. If that host panics, the outage is larger than the affected code path sounds.
Security teams should therefore avoid ranking it by name recognition. This is not OpenSSL, Exchange, or a browser zero-day. It is a Linux kernel bridge race. In the wrong place, that is enough to matter.
The right response is disciplined rather than dramatic: identify bridge-bearing systems, check vendor kernel status, prioritize shared or exposed hosts, reduce unnecessary local access to network administration paths, and schedule the kernel update with the seriousness you would give any infrastructure crash fix.
The Bridge Fix Leaves Administrators With a Short Checklist
CVE-2026-46086 is a reminder that kernel security work often arrives as a narrow patch with broad operational implications. The interesting part is not that a pointer needed a snapshot; it is that a small assumption in Linux bridge code can sit beneath so many modern environments.- Systems using Linux bridge for virtualization, containers, routing, lab networks, or appliances should be checked before ordinary desktops with no bridge configuration.
- The likely impact described publicly is denial of service through a NULL pointer dereference, not confirmed remote code execution or privilege escalation.
- The fix relies on consistent
READ_ONCE()andWRITE_ONCE()access to prevent RCU readers from seeing differentf->dstvalues during one access sequence. - Vendor kernels matter more than upstream commit IDs for most administrators, because distributions and appliances may backport the fix without changing to a visibly new kernel series.
- Container and CI hosts deserve extra scrutiny because a “local” kernel bug may be reachable by workloads that are not fully trusted.
- Monitoring tools that read bridge forwarding state should be considered part of the exposure model, especially on hosts where bridge ports and local FDB entries change frequently.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:09:46-07:00
NVD - CVE-2026-46086
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:09:46-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH] net: bridge: use a stable FDB dst snapshot in RCU readers — Linux Stable Kernel Updates
Stable Kernel: [PATCH] net: bridge: use a stable FDB dst snapshot in RCU readerswww.spinics.net - Related coverage: korg.docs.kernel.org
- Related coverage: gitlab.com
- Related coverage: kernel.org
The Linux Kernel Archives
www.kernel.org
- Related coverage: kernel.googlesource.com
- Official source: github.com
GitHub - gregkh/linux: Linux kernel stable tree mirror
Linux kernel stable tree mirror. Contribute to gregkh/linux development by creating an account on GitHub.
github.com
- Related coverage: windowsforum.com
act_gate RCU snapshot fix: stable patch for Linux traffic-control race (CVE-2026-23245)
The Linux kernel’s act_gate traffic-control action is getting a focused security fix after maintainers identified a schedule-lifetime race that can appear when the gate is being replaced while either the hrtimer callback or the dump path is still traversing the schedule list. The upstream patch...
windowsforum.com
- Related coverage: android.googlesource.com
- Related coverage: kernel.ritovision.com
The Linux Kernel Archives
kernel.ritovision.com
- Related coverage: archives.kernel-recipes.org
- Related coverage: archive.fosdem.org
