Linux kernel maintainers disclosed CVE-2026-46102 on May 27, 2026, after fixing a stream parser bug in which aborted message assembly could leave a partially built socket buffer referenced and repeatedly leak memory. The flaw is not a flashy remote-code-execution headline, and NVD had not yet assigned a CVSS score at publication time. But its practical meaning is familiar to anyone who operates Linux at scale: a small cleanup mistake in a low-level network path can become a denial-of-service problem when it is reachable often enough. The fix is only eight lines long; the operational lesson is much larger.
CVE-2026-46102 lives in the Linux kernel’s stream parser code, a subsystem designed to help protocol handlers assemble message-oriented data from byte streams. That phrasing sounds abstract, but it describes one of the oldest hard problems in network software: the wire gives you bytes, while applications and protocols want messages.
The vulnerability centers on
That is the entire bug, and it is enough. A missing release in a hot or repeatedly triggerable path is not merely a theoretical leak; it is a pressure valve left open in kernel memory. If an attacker or misbehaving peer can repeatedly drive the parser into that abort condition, memory exhaustion becomes the obvious failure mode.
The repair is correspondingly direct. The patch frees
That distinction matters. Kernel fixes are rarely just “free the thing.” They are “free the thing in the one path where doing so is safe, without racing the other path that also believes it owns cleanup.” CVE-2026-46102 is a useful reminder that memory safety bugs can hide not only in exotic pointer arithmetic, but in the choreography of shutdown.
The absence of a score is not the same as the absence of risk. It means the scoring bureaucracy has not yet completed its work. For defenders, the useful facts are already present: this is a kernel bug, it involves network parsing, it leaks memory, and it can reportedly be triggered repeatedly to exhaust memory.
There is a reasonable ceiling on panic here. The public description does not claim arbitrary code execution, privilege escalation, kernel address disclosure, or data theft. It describes a resource-exhaustion condition, which usually places it in the denial-of-service family unless later analysis expands the impact.
But denial of service in the kernel is not benign. A memory leak in user space may kill a process. A memory leak in kernel space can degrade the host, trigger the out-of-memory killer, destabilize unrelated workloads, or force a reboot. On a desktop, that is disruptive. On a server, router, appliance, hypervisor host, or Kubernetes node, it can become an availability incident.
The scoring delay also exposes a recurring weakness in vulnerability management workflows. Many organizations have tuned patch prioritization around CVSS thresholds because they need automation. That is understandable. It is also brittle when a newly published CVE has enough technical detail to justify action before the score arrives.
That is why the abort path matters. Security bugs often emerge where software exits the happy path: timeout, cancellation, teardown, error handling, and partial cleanup. These paths run less often in ordinary testing, but they are exactly the paths adversarial traffic tries to exercise.
In this case, the parser could hold a partially assembled message in
Repeated triggering is the phrase that changes the risk profile. A one-time leak may be a bug. A repeatable leak is a lever. Resource exhaustion attacks are often built from exactly this kind of lever: make the target do a small amount of unreclaimed work, repeat, and wait for the system’s own accounting to become the attacker’s payload.
The kernel patch notes mention a message assembly timeout as one example of an abort. That does not by itself prove easy remote exploitation across every configuration. It does, however, point administrators toward the right question: where do deployed workloads use affected stream parser paths, and can untrusted peers cause those paths to abort repeatedly?
The patch also avoids changing
The public patch trail shows the fix moving through the normal upstream and stable channels, with stable backports referenced by NVD. That is exactly what administrators want to see for a kernel flaw: a small upstream fix, a clear affected subsystem, and backports into maintained series rather than a vague advisory that leaves downstream distributions to improvise.
Still, backport presence does not mean every running machine is fixed. Linux users rarely run “the kernel” in the abstract. They run a vendor kernel, cloud image kernel, appliance kernel, Android-derived kernel, container host kernel, NAS kernel, firewall kernel, or long-term-support branch with vendor-specific backports. The relevant question is not whether the upstream commit exists, but whether your kernel package includes the fix.
That subtlety is especially important for WindowsForum readers who live in mixed environments. A Windows admin may encounter this bug not on a personal Linux desktop, but inside WSL-adjacent workflows, Linux-based security appliances, hypervisor infrastructure, container nodes, storage systems, CI runners, or cloud images that underpin Windows services. Modern Windows shops are rarely Windows-only below the waterline.
A kernel memory-exhaustion bug is an availability vulnerability with system-wide consequences. If the affected path can be reached remotely or from a less-trusted network zone, the attacker may not need credentials, code execution, or persistence. They may only need patience and a way to keep inducing partial message assembly failures.
Even when exploitation requires local access or a specific protocol configuration, the impact can be material in multi-tenant systems. Container hosts, shared build servers, VPN gateways, ingress proxies, storage heads, and edge appliances all depend on the host kernel remaining healthy under hostile or malformed input. Memory pressure does not respect the neat boundaries of service ownership.
There is also a monitoring problem. Slow kernel memory leaks can look like ordinary resource drift until they become acute. The first symptom may be rising memory pressure, unexpected reclaim behavior, killed processes, degraded network service, or a node that needs to be drained and rebooted. By the time the incident is visible, the triggering traffic may have rotated away.
That does not mean CVE-2026-46102 should be treated as a five-alarm emergency in every environment. It means it should not be dismissed because it is “just a leak.” The right operational posture is measured urgency: identify exposure, confirm vendor fixes, schedule kernel updates, and watch for memory-pressure anomalies on systems that process untrusted network traffic.
For defenders, this creates a timing gap. The primary source tells you a bug exists and has been fixed. The vulnerability database tells you enrichment is pending. The distribution advisory may not yet have a polished page. The scanner may not recognize your patched-but-version-unchanged enterprise kernel. Meanwhile, the patch itself is public.
That gap is not merely administrative. Attackers and researchers can read patches too. A concise fix that frees an object in an abort path gives a competent reader a strong hint about the failure mode. In many cases, turning that into a practical reproducer is easier than waiting for a vendor blog post.
The Linux kernel community’s approach has a tradeoff. Publishing fixes quickly through open channels gets patches to users and vendors fast. It also means the disclosure artifact is often the commit message itself. Security teams that still expect a single advisory to carry all context will miss the early window where practical risk decisions need to be made.
The answer is not to panic at every kernel CVE. It is to build processes that can ingest patch-level facts. A vulnerability with no CVSS score but a clear stable backport and an exhaustion primitive deserves more attention than a fully scored issue that is unreachable in your environment.
Developers run Linux containers on Windows workstations. Enterprises host Windows-facing applications behind Linux load balancers and ingress controllers. Security tooling, backup systems, network appliances, EDR backends, SIEM collectors, and cloud-native platforms often sit on Linux kernels even when the business application estate is mostly Windows. Azure, like every major cloud, makes Linux a first-class infrastructure substrate.
WSL deserves a careful mention here. The user-supplied CVE material concerns the Linux kernel, not Windows itself. Whether a given WSL environment is affected depends on the WSL kernel version and whether Microsoft’s shipped kernel includes the relevant backport. That is not something to infer from the upstream CVE alone.
The same logic applies to Docker Desktop, local Kubernetes clusters, and virtual appliances used by Windows-heavy teams. A Windows laptop may be fully patched through Windows Update while still running Linux components whose update lifecycle is separate, delayed, or hidden behind a vendor bundle. Security ownership follows the kernel doing the work, not the logo on the chassis.
For IT pros, CVE-2026-46102 is another reason to keep a cross-platform asset view. The practical checklist starts with kernel versioning, but it does not end there. You need to know which systems expose network-facing services that rely on affected code paths, which vendors have shipped patched kernels, and which appliances cannot be updated without a maintenance window.
Enterprise Linux vendors routinely backport security fixes without moving to a visibly newer upstream kernel. Cloud providers may publish new machine images while older running instances remain on the previous kernel until rebooted. Appliance vendors may quietly consume a stable patch weeks later. Container users may update images and still forget that the host kernel, not the container image, decides kernel vulnerability exposure.
The most reliable answer will come from the vendor kernel changelog, security advisory, or package metadata. If your vendor maps CVE identifiers in changelogs, search directly for CVE-2026-46102. If the CVE mapping has not landed yet, search for the patch subject: “net: strparser: fix skb_head leak in strp_abort_strp.” That string is more useful than the score that NVD has not yet assigned.
Administrators should also remember that applying a kernel package is not the same as running it. Linux hosts generally need a reboot or live-patching mechanism before the fixed kernel is active. In fleets with long uptimes, “installed” and “booted” can diverge for months.
That distinction is not academic. A scanner that checks package state may report fixed while the machine is still executing the vulnerable kernel. Conversely, a scanner that only checks version numbers may flag a vendor-backported kernel as vulnerable when it is not. Kernel CVEs punish shallow inventory.
This is a pattern the industry still struggles to communicate. The most dramatic vulnerabilities rewrite the story of a system: code execution, sandbox escape, credential theft. The less dramatic ones degrade the system until it cannot provide service. In infrastructure, the second category can still be mission-critical.
The patch’s restraint is also instructive. It does not redesign the stream parser. It does not add a new policy layer. It simply ensures that abort means abort: release the partially assembled message, clear the state, and leave final synchronized cleanup to the existing path. Good security fixes often look like good engineering hygiene.
For developers, the lesson is to test teardown paths with the same aggression as parsing success paths. Timeouts, cancellations, and partial-message aborts are not boring edge cases; they are adversarial surfaces. For operators, the lesson is to treat recurring memory growth under malformed or incomplete network traffic as a security signal, not merely an SRE nuisance.
That uncertainty should shape the response. Systems with minimal network exposure and no relevant parser users are lower priority. Internet-facing infrastructure, multi-tenant hosts, network appliances, and systems that process untrusted streams deserve faster verification. Environments with strict maintenance windows should at least plan the reboot path now rather than waiting for a scanner panic later.
Security teams should also avoid overclaiming. There is no need to describe CVE-2026-46102 as a remote takeover. The known impact is memory exhaustion from a kernel leak. Inflating that into a more cinematic vulnerability does not help defenders; it makes future advisories easier to ignore.
The more honest framing is also more useful. This is a kernel availability bug in a network parser, fixed upstream and referenced in stable backports, with NVD scoring still pending. It is exactly the kind of vulnerability that can disappear cleanly with routine kernel maintenance—or linger for years in appliances, forgotten hosts, and “temporary” infrastructure.
The Bug Is Small Because the Kernel Is Not
CVE-2026-46102 lives in the Linux kernel’s stream parser code, a subsystem designed to help protocol handlers assemble message-oriented data from byte streams. That phrasing sounds abstract, but it describes one of the oldest hard problems in network software: the wire gives you bytes, while applications and protocols want messages.The vulnerability centers on
strp_abort_strp(), the abort path used when parsing is stopped, including after a message assembly timeout. According to the kernel description, the parser could still hold a reference to a partially assembled message in strp->skb_head. Because that socket buffer was not released during abort, the memory could remain allocated after the parser had otherwise moved on.That is the entire bug, and it is enough. A missing release in a hot or repeatedly triggerable path is not merely a theoretical leak; it is a pressure valve left open in kernel memory. If an attacker or misbehaving peer can repeatedly drive the parser into that abort condition, memory exhaustion becomes the obvious failure mode.
The repair is correspondingly direct. The patch frees
strp->skb_head, clears the pointer, and resets parser state such as skb_nextp and need_bytes in the abort path. The maintainers deliberately left strp_stop() alone, preserving the final cleanup behavior in strp_done() after timers and work items have been synchronized.That distinction matters. Kernel fixes are rarely just “free the thing.” They are “free the thing in the one path where doing so is safe, without racing the other path that also believes it owns cleanup.” CVE-2026-46102 is a useful reminder that memory safety bugs can hide not only in exotic pointer arithmetic, but in the choreography of shutdown.
The Missing CVSS Score Is Not a Free Pass
At the time the record appeared in NVD, CVE-2026-46102 was marked as awaiting enrichment, with no NVD CVSS v4, v3, or v2 score provided. That will tempt some vulnerability dashboards to rank it as unknown, low-priority, or simply noisy until the enrichment pipeline catches up. That would be the wrong reading.The absence of a score is not the same as the absence of risk. It means the scoring bureaucracy has not yet completed its work. For defenders, the useful facts are already present: this is a kernel bug, it involves network parsing, it leaks memory, and it can reportedly be triggered repeatedly to exhaust memory.
There is a reasonable ceiling on panic here. The public description does not claim arbitrary code execution, privilege escalation, kernel address disclosure, or data theft. It describes a resource-exhaustion condition, which usually places it in the denial-of-service family unless later analysis expands the impact.
But denial of service in the kernel is not benign. A memory leak in user space may kill a process. A memory leak in kernel space can degrade the host, trigger the out-of-memory killer, destabilize unrelated workloads, or force a reboot. On a desktop, that is disruptive. On a server, router, appliance, hypervisor host, or Kubernetes node, it can become an availability incident.
The scoring delay also exposes a recurring weakness in vulnerability management workflows. Many organizations have tuned patch prioritization around CVSS thresholds because they need automation. That is understandable. It is also brittle when a newly published CVE has enough technical detail to justify action before the score arrives.
Stream Parsers Turn Edge Cases Into Attack Surface
The Linux stream parser exists because TCP does not preserve message boundaries. Protocols layered over a stream must decide when a complete message has arrived, what to do with partial data, and how long they are willing to wait. Timeouts are therefore not exceptional in the philosophical sense; they are part of the design.That is why the abort path matters. Security bugs often emerge where software exits the happy path: timeout, cancellation, teardown, error handling, and partial cleanup. These paths run less often in ordinary testing, but they are exactly the paths adversarial traffic tries to exercise.
In this case, the parser could hold a partially assembled message in
skb_head when the abort occurred. An skb, or socket buffer, is the kernel’s fundamental packet buffer structure. Leaking one is not like forgetting to close a cosmetic UI handle; it means kernel networking memory remains tied up after it should have been returned.Repeated triggering is the phrase that changes the risk profile. A one-time leak may be a bug. A repeatable leak is a lever. Resource exhaustion attacks are often built from exactly this kind of lever: make the target do a small amount of unreclaimed work, repeat, and wait for the system’s own accounting to become the attacker’s payload.
The kernel patch notes mention a message assembly timeout as one example of an abort. That does not by itself prove easy remote exploitation across every configuration. It does, however, point administrators toward the right question: where do deployed workloads use affected stream parser paths, and can untrusted peers cause those paths to abort repeatedly?
The Eight-Line Fix Carries a Whole Maintenance Philosophy
The fix adds a guarded free ofstrp->skb_head and resets parser bookkeeping in strp_abort_strp(). In plain English, when the parser is being aborted, it now drops the partially assembled message it was holding and returns to a state that does not point into stale or already-owned data. That is the kind of change that looks obvious only after someone has identified the missing state transition.The patch also avoids changing
strp_stop(). That restraint is not incidental. Kernel networking code is full of timers, deferred work, callbacks, and shutdown sequencing; moving cleanup into the wrong layer can trade a leak for a double free or a race.The public patch trail shows the fix moving through the normal upstream and stable channels, with stable backports referenced by NVD. That is exactly what administrators want to see for a kernel flaw: a small upstream fix, a clear affected subsystem, and backports into maintained series rather than a vague advisory that leaves downstream distributions to improvise.
Still, backport presence does not mean every running machine is fixed. Linux users rarely run “the kernel” in the abstract. They run a vendor kernel, cloud image kernel, appliance kernel, Android-derived kernel, container host kernel, NAS kernel, firewall kernel, or long-term-support branch with vendor-specific backports. The relevant question is not whether the upstream commit exists, but whether your kernel package includes the fix.
That subtlety is especially important for WindowsForum readers who live in mixed environments. A Windows admin may encounter this bug not on a personal Linux desktop, but inside WSL-adjacent workflows, Linux-based security appliances, hypervisor infrastructure, container nodes, storage systems, CI runners, or cloud images that underpin Windows services. Modern Windows shops are rarely Windows-only below the waterline.
The DoS Label Understates the Blast Radius
Security teams have a habit of mentally sorting vulnerabilities into a hierarchy: remote code execution at the top, privilege escalation close behind, information disclosure somewhere in the middle, denial of service near the bottom. That hierarchy is convenient, and sometimes dangerously lazy.A kernel memory-exhaustion bug is an availability vulnerability with system-wide consequences. If the affected path can be reached remotely or from a less-trusted network zone, the attacker may not need credentials, code execution, or persistence. They may only need patience and a way to keep inducing partial message assembly failures.
Even when exploitation requires local access or a specific protocol configuration, the impact can be material in multi-tenant systems. Container hosts, shared build servers, VPN gateways, ingress proxies, storage heads, and edge appliances all depend on the host kernel remaining healthy under hostile or malformed input. Memory pressure does not respect the neat boundaries of service ownership.
There is also a monitoring problem. Slow kernel memory leaks can look like ordinary resource drift until they become acute. The first symptom may be rising memory pressure, unexpected reclaim behavior, killed processes, degraded network service, or a node that needs to be drained and rebooted. By the time the incident is visible, the triggering traffic may have rotated away.
That does not mean CVE-2026-46102 should be treated as a five-alarm emergency in every environment. It means it should not be dismissed because it is “just a leak.” The right operational posture is measured urgency: identify exposure, confirm vendor fixes, schedule kernel updates, and watch for memory-pressure anomalies on systems that process untrusted network traffic.
NVD’s “Awaiting Enrichment” Moment Shows the Patch Gap
The NVD record for CVE-2026-46102 landed with the essential kernel description and multiple stable references, but without NVD-provided scoring or weakness classification. This is increasingly normal in the Linux CVE era, where kernel.org-originated CVEs can appear in large numbers with terse descriptions and patch links before downstream advisories have caught up.For defenders, this creates a timing gap. The primary source tells you a bug exists and has been fixed. The vulnerability database tells you enrichment is pending. The distribution advisory may not yet have a polished page. The scanner may not recognize your patched-but-version-unchanged enterprise kernel. Meanwhile, the patch itself is public.
That gap is not merely administrative. Attackers and researchers can read patches too. A concise fix that frees an object in an abort path gives a competent reader a strong hint about the failure mode. In many cases, turning that into a practical reproducer is easier than waiting for a vendor blog post.
The Linux kernel community’s approach has a tradeoff. Publishing fixes quickly through open channels gets patches to users and vendors fast. It also means the disclosure artifact is often the commit message itself. Security teams that still expect a single advisory to carry all context will miss the early window where practical risk decisions need to be made.
The answer is not to panic at every kernel CVE. It is to build processes that can ingest patch-level facts. A vulnerability with no CVSS score but a clear stable backport and an exhaustion primitive deserves more attention than a fully scored issue that is unreachable in your environment.
Windows Shops Still Own Linux Kernel Risk
It is tempting to frame CVE-2026-46102 as “Linux news” and therefore outside the daily concern of Windows administrators. That view belongs to another decade. The modern Microsoft ecosystem is layered over Linux in more places than many organizations inventory well.Developers run Linux containers on Windows workstations. Enterprises host Windows-facing applications behind Linux load balancers and ingress controllers. Security tooling, backup systems, network appliances, EDR backends, SIEM collectors, and cloud-native platforms often sit on Linux kernels even when the business application estate is mostly Windows. Azure, like every major cloud, makes Linux a first-class infrastructure substrate.
WSL deserves a careful mention here. The user-supplied CVE material concerns the Linux kernel, not Windows itself. Whether a given WSL environment is affected depends on the WSL kernel version and whether Microsoft’s shipped kernel includes the relevant backport. That is not something to infer from the upstream CVE alone.
The same logic applies to Docker Desktop, local Kubernetes clusters, and virtual appliances used by Windows-heavy teams. A Windows laptop may be fully patched through Windows Update while still running Linux components whose update lifecycle is separate, delayed, or hidden behind a vendor bundle. Security ownership follows the kernel doing the work, not the logo on the chassis.
For IT pros, CVE-2026-46102 is another reason to keep a cross-platform asset view. The practical checklist starts with kernel versioning, but it does not end there. You need to know which systems expose network-facing services that rely on affected code paths, which vendors have shipped patched kernels, and which appliances cannot be updated without a maintenance window.
The Real Test Is Vendor Backports, Not Upstream Awareness
The upstream fix appears in stable kernel references, including long-term branches. That is good news, but it is only the beginning of the defender’s work. Distribution kernels often carry thousands of patches, and their version strings do not always make vulnerability status obvious.Enterprise Linux vendors routinely backport security fixes without moving to a visibly newer upstream kernel. Cloud providers may publish new machine images while older running instances remain on the previous kernel until rebooted. Appliance vendors may quietly consume a stable patch weeks later. Container users may update images and still forget that the host kernel, not the container image, decides kernel vulnerability exposure.
The most reliable answer will come from the vendor kernel changelog, security advisory, or package metadata. If your vendor maps CVE identifiers in changelogs, search directly for CVE-2026-46102. If the CVE mapping has not landed yet, search for the patch subject: “net: strparser: fix skb_head leak in strp_abort_strp.” That string is more useful than the score that NVD has not yet assigned.
Administrators should also remember that applying a kernel package is not the same as running it. Linux hosts generally need a reboot or live-patching mechanism before the fixed kernel is active. In fleets with long uptimes, “installed” and “booted” can diverge for months.
That distinction is not academic. A scanner that checks package state may report fixed while the machine is still executing the vulnerable kernel. Conversely, a scanner that only checks version numbers may flag a vendor-backported kernel as vulnerable when it is not. Kernel CVEs punish shallow inventory.
Memory Leaks Are Where Reliability and Security Meet
CVE-2026-46102 sits at the overlap of reliability engineering and security response. The underlying defect is a cleanup bug. The security consequence is resource exhaustion. The fix improves correctness, but the reason it receives a CVE is that correctness failures in kernel networking can be externally meaningful.This is a pattern the industry still struggles to communicate. The most dramatic vulnerabilities rewrite the story of a system: code execution, sandbox escape, credential theft. The less dramatic ones degrade the system until it cannot provide service. In infrastructure, the second category can still be mission-critical.
The patch’s restraint is also instructive. It does not redesign the stream parser. It does not add a new policy layer. It simply ensures that abort means abort: release the partially assembled message, clear the state, and leave final synchronized cleanup to the existing path. Good security fixes often look like good engineering hygiene.
For developers, the lesson is to test teardown paths with the same aggression as parsing success paths. Timeouts, cancellations, and partial-message aborts are not boring edge cases; they are adversarial surfaces. For operators, the lesson is to treat recurring memory growth under malformed or incomplete network traffic as a security signal, not merely an SRE nuisance.
The Patch Is Clear, but the Exposure Map Is Not
The public information available so far does not establish a universal exploitation recipe. It tells us the kernel stream parser could leak anskb when aborted and that repeated triggering could exhaust memory. It does not, by itself, enumerate every protocol, module, distribution, appliance, or workload configuration that exposes the affected path to untrusted input.That uncertainty should shape the response. Systems with minimal network exposure and no relevant parser users are lower priority. Internet-facing infrastructure, multi-tenant hosts, network appliances, and systems that process untrusted streams deserve faster verification. Environments with strict maintenance windows should at least plan the reboot path now rather than waiting for a scanner panic later.
Security teams should also avoid overclaiming. There is no need to describe CVE-2026-46102 as a remote takeover. The known impact is memory exhaustion from a kernel leak. Inflating that into a more cinematic vulnerability does not help defenders; it makes future advisories easier to ignore.
The more honest framing is also more useful. This is a kernel availability bug in a network parser, fixed upstream and referenced in stable backports, with NVD scoring still pending. It is exactly the kind of vulnerability that can disappear cleanly with routine kernel maintenance—or linger for years in appliances, forgotten hosts, and “temporary” infrastructure.
The Eight Lines Admins Should Turn Into Action
The immediate story is a small kernel fix, but the operational story is about closing the distance between upstream patches and running systems. CVE-2026-46102 does not demand theater. It demands inventory discipline, vendor tracking, and a bias toward rebooting into fixed kernels when the affected systems matter.- Confirm whether your Linux distributions, cloud images, appliances, and WSL-related kernels have published fixes or backports for CVE-2026-46102.
- Search vendor changelogs for the patch subject if CVE tagging has not yet propagated through package metadata.
- Prioritize systems that expose network services to untrusted clients, especially multi-tenant hosts, edge systems, container nodes, and infrastructure appliances.
- Verify the running kernel after patching, because installing a fixed kernel package does not protect a host that has not rebooted into it.
- Treat unexplained kernel memory pressure or repeated network-parser timeouts as potentially security-relevant until patched systems and traffic patterns say otherwise.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:12:18-07:00
NVD - CVE-2026-46102
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:12:18-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: opennet.ru
- Related coverage: ubuntu.com
- Related coverage: cve.imfht.com
CVE-2026-31621: Linux kernel 安全漏洞
## 概述 Linux 内核 `bnge` 驱动在 `auxiliary_device_add()` 失败时，错误路径调用 `auxiliary_device_uninit()` 后未立即返回，导致后续代码解引用已释放的 `bd->auxr_dev`（已被设为 NULL），引发空指针解引用。修复方法是在该处添加缺失的 `return`。 ## 影响版本 - 未明确具体版本范围，涉及使用
cve.imfht.com
- Related coverage: android.googlesource.com
- Related coverage: git.zx2c4.com
wireguard-linux - WireGuard for the Linux kernel
git.zx2c4.com
