CVE-2026-46085 is a newly published Linux kernel vulnerability, received by NVD from kernel.org on May 27, 2026, in the RxRPC rxkad security code, where malformed encrypted packet lengths could trigger incorrect crypto handling and a remotely reachable kernel warning. The record is still awaiting NVD enrichment, which means the familiar CVSS score and severity labels are absent for now. But the absence of a score should not be mistaken for the absence of a story. This is a small patch in a niche subsystem that says something large about how modern kernel risk is increasingly hiding in the corners most administrators never consciously enable.
The short version of CVE-2026-46085 is almost disarmingly plain: RxRPC’s rxkad path did not properly handle a packet whose cryptographic length was not aligned as expected. The fix rounds the length down before handing it to the crypto layer, treats non-memory decryption failures as protocol errors, and removes a
That last detail is the tell. Kernel warnings are not supposed to be remote user interface elements. A
The patch also adds a traceable abort reason for the unaligned crypto case. That is a healthier model: reject malformed input, emit telemetry, and move on. The kernel should not panic, shout, or expose fragile internal assumptions just because a packet arrived with an inconvenient shape.
This is not the sort of bug that will dominate mainstream security headlines. There is no NVD score yet, no vendor-branded logo, and no public proof-of-concept tied to this CVE in the material at hand. But for WindowsForum’s sysadmin-heavy readership, the interesting part is not theatrical severity. It is the way an obscure protocol module can become part of the operational security perimeter the moment it is present, loadable, or used by an application stack.
That heritage matters because it explains why many administrators have never knowingly deployed RxRPC while still finding the module present in a distribution kernel. Linux distributions tend to ship broad hardware and protocol support, especially in general-purpose kernels. A feature can be obscure, lightly used, and still available enough to be part of the risk conversation.
The modern kernel is full of these half-visible surfaces. They are not “legacy” in the sense of being dead, and they are not “mainstream” in the sense of being in every dashboard. They sit between those categories: maintained, useful to a minority, compiled into or packaged alongside general systems, and often autoloadable when a sufficiently specific code path is exercised.
For desktop Linux users, this may sound distant. For enterprise administrators, it should sound familiar. The same dynamic appears in filesystem drivers, tunneling modules, packet classifiers, compatibility layers, and crypto helpers. You do not have to use a feature every day for it to be part of your patch-management problem.
That is classic defensive kernel programming: sanitize before delegation, distinguish resource failure from malformed input, and avoid turning diagnostics into reachable behavior. The best kernel patches often read this way. They are less about a single dramatic exploit primitive than about closing the gap between “this should never happen” and “the network is allowed to send nonsense.”
The removed warning is especially important because warning paths have a history of becoming nuisance vulnerabilities. A remotely triggerable warning can fill logs, trip monitoring, degrade confidence in a system, or in some configurations contribute to denial-of-service-like behavior. Even when it is not memory corruption, it is still externally induced kernel distress.
There is also a subtle cultural shift here. Older kernel code often treated impossible states as programmer errors. Modern exposed subsystems have to treat many impossible states as attacker-controlled inputs. CVE-2026-46085 is a reminder that the boundary between those worlds is not determined by developer intent; it is determined by reachability.
This is where Linux kernel security often diverges from application security. A web application CVE may arrive with a crisp exploit narrative: unauthenticated remote code execution, fixed in version X, exploited in the wild. Kernel CVEs frequently land as patch-derived records with terse descriptions and several stable backport commits. The people who know how serious they are may need to inspect code paths, configs, module loading, and distribution packaging.
For CVE-2026-46085, the practical first question is whether a system has AF_RXRPC and RXKAD support available and whether anything uses it. That cannot be answered by the CVE record alone. It depends on the distribution kernel, configuration choices, installed modules, workload behavior, and whether AFS or other RxRPC consumers are in play.
The lack of a score should therefore push teams toward inventory, not complacency. A low-profile kernel bug in an unused module may be a routine patch. The same bug in a reachable service path on a multi-user or network-facing host is a different operational matter. CVSS will eventually simplify the conversation, but it will not replace local context.
That background matters because security teams do not triage vulnerabilities as isolated dictionary entries. They triage them amid patterns. When a niche subsystem appears in multiple advisories, patch discussions, and mitigations within a short window, it becomes a risk cluster even if each individual CVE has a distinct root cause.
This is also why “we do not use AFS” is not always the end of the conversation. It may be true, and it may lower exposure substantially. But administrators still need to know whether the module can be loaded, whether unprivileged users can trigger relevant paths, whether containers can reach the needed interfaces, and whether distribution hardening already blocks the risky route.
There is a temptation to overcorrect here. Not every RxRPC bug means every Linux host is in imminent danger. But the opposite error is more common in enterprise estates: assuming that obscure equals absent. The last few years of kernel security have repeatedly punished that assumption.
That mixed estate is where bugs like CVE-2026-46085 become easy to mishandle. The Windows patch routine may be mature, calendarized, and reported. The Linux kernel routine may be fragmented among platform teams, DevOps owners, appliance vendors, and cloud image maintainers. A vulnerability in a niche kernel subsystem can fall between those ownership models.
WSL deserves a careful mention, not because this CVE is known to be a WSL-specific threat, but because WSL has normalized Linux kernels on Windows-managed endpoints. Security teams that once thought of Linux as “server-side” now have developer workstations running Linux userlands and kernel integrations as part of daily workflows. Whether RxRPC is present or reachable in a given WSL kernel is a technical inventory question, not a branding question.
The more important point is governance. If your vulnerability process treats Linux kernel CVEs as someone else’s problem until there is a branded exploit, you are late by design. CVE-2026-46085 is precisely the sort of quiet kernel maintenance item that tests whether cross-platform patching is real or merely aspirational.
There is a difference between logging a malformed packet and letting that packet trip a kernel warning macro. The former is a controlled administrative signal. The latter is a sign that an internal assumption escaped into the threat model. Attackers love those seams because they often reveal where code was written for correctness under friendly conditions rather than resilience under hostile ones.
This distinction is not unique to Linux. Windows administrators have seen the same pattern in event log floods, driver assertion failures, and crash-prone parsing paths. The platform differs, but the lesson is universal: diagnostics that are safe in a lab can become liabilities when reachable from a network boundary.
CVE-2026-46085 is therefore not only about crypto length alignment. It is about the discipline of making the kernel boring under malformed input. Boring is a virtue. Boring means reject, trace, and continue.
For source builders and distribution maintainers, the commit message is clear enough: the rxkad packet verification path needed to prevent misaligned crypto lengths, abort on non-ENOMEM decrypt errors, and stop emitting a remotely triggerable warning. For everyone else, the job is less glamorous. Find the vendor advisory, identify the kernel build that contains the fix, roll it through test, and reboot systems that need a new kernel in memory.
That reboot requirement is still one of Linux’s operational pain points. Live patching can help in some environments, but network-stack fixes in modular or complex paths often still lead administrators back to the old truth: the patched package is not the same as the running kernel. Inventory tools should report both installed and active versions.
This is where compliance dashboards can lie by omission. A server may show an updated kernel package and still be running the vulnerable one until reboot. A golden image may be patched while long-lived instances are not. A container host may be rebuilt while developer laptops lag for weeks. Kernel CVEs reward operational precision.
Administrators should also avoid cargo-culting mitigations from adjacent vulnerabilities. Dirty Frag discussions often mentioned RxRPC alongside IPsec modules, but CVE-2026-46085 is its own issue with its own fix. If you disable a module, do it because your exposure analysis says the feature is unnecessary, not because a social post bundled several scary names together.
The cleanest path remains boring: patch the kernel through the distribution’s supported channel. If immediate patching is not possible, then module policy, workload isolation, and network exposure reduction can buy time. But those measures should be tracked as exceptions, not treated as permanent architecture.
In mature environments, this becomes a configuration-management problem. If RxRPC is not approved anywhere, enforce that as policy. If it is approved only for AFS clients, scope it to those hosts and monitor accordingly. If nobody knows, CVE-2026-46085 is a useful excuse to find out.
Network-facing kernel code is particularly unforgiving because packets are hostile by default. The kernel has to parse, authenticate, decrypt, route, and account for data at speed. Every optimization and every assumption is under pressure. Crypto adds another layer, because algorithms often expect block sizes, alignment, padding, and failure semantics to be respected exactly.
Rxkad is especially emblematic because it sits at the intersection of old protocol assumptions and modern hardening expectations. Kerberos-derived AFS security code was not born in today’s threat climate of cloud multi-tenancy, container escape research, and automated exploit diffing. The code can be maintained and still carry design assumptions that need periodic tightening.
That is not an indictment of Linux. It is the reality of all long-lived operating systems. Windows has decades-old subsystems with modern patch trains; Linux has protocol modules that matter to small but real user bases; BSDs have their own inherited surfaces. Security engineering is increasingly the art of making old interfaces survive new adversaries.
This is the recurring frustration of kernel security in 2026. The industry has built enormous machinery around vulnerability identifiers, but the identifiers are often thinner than the patches that caused them. A terse commit message may carry more operational truth than the polished database entry that appears later.
CVE-2026-46085 also shows why sysadmins should read vulnerability descriptions with an engineer’s suspicion. “Misaligned crypto length” is not flashy, but it tells you the bug is in packet handling, crypto boundaries, and error behavior. “Remotely triggered warning” tells you the input path is reachable enough to matter. “Awaiting enrichment” tells you the public scoring process has not caught up.
That is enough to act. Not to overreact, not to declare an internet-wide emergency, but to patch with discipline and verify with evidence. The quiet CVEs are often the ones that reveal whether a security program is driven by risk or by headlines.
The forward-looking lesson is that Linux administrators, Windows administrators, and the many people now responsible for both need to treat obscure kernel subsystems as first-class inventory items. CVE-2026-46085 will likely disappear into the next stable kernel rollup for many users, which is exactly what should happen. But the pattern will return: a small parser flaw, a niche module, a missing score, a patch that says more than the advisory. The organizations that handle those calmly now will be better prepared when the next quiet kernel corner becomes the loudest part of the incident channel.
The Vulnerability Is Small, but the Attack Surface Is Not Imaginary
The short version of CVE-2026-46085 is almost disarmingly plain: RxRPC’s rxkad path did not properly handle a packet whose cryptographic length was not aligned as expected. The fix rounds the length down before handing it to the crypto layer, treats non-memory decryption failures as protocol errors, and removes a WARN_ON_ONCE() that could be triggered from the network.That last detail is the tell. Kernel warnings are not supposed to be remote user interface elements. A
WARN_ON_ONCE() is a developer’s flare gun, useful when debugging assumptions during development, but awkward when reachable through hostile input in production. Even if it does not hand an attacker root, it turns an internal diagnostic into something a remote peer can intentionally prod.The patch also adds a traceable abort reason for the unaligned crypto case. That is a healthier model: reject malformed input, emit telemetry, and move on. The kernel should not panic, shout, or expose fragile internal assumptions just because a packet arrived with an inconvenient shape.
This is not the sort of bug that will dominate mainstream security headlines. There is no NVD score yet, no vendor-branded logo, and no public proof-of-concept tied to this CVE in the material at hand. But for WindowsForum’s sysadmin-heavy readership, the interesting part is not theatrical severity. It is the way an obscure protocol module can become part of the operational security perimeter the moment it is present, loadable, or used by an application stack.
RxRPC Is the Kind of Kernel Feature Everyone Forgets Until It Matters
RxRPC is a Linux networking facility that provides reliable remote procedure call-style communication over UDP. In practice, its best-known client is AFS, the Andrew File System, a distributed filesystem with roots in an older era of networked Unix infrastructure. The Linux kernel’s AF_RXRPC support exists so both kernel and user-space components can use this transport, and rxkad is the Kerberos-flavored security layer associated with that ecosystem.That heritage matters because it explains why many administrators have never knowingly deployed RxRPC while still finding the module present in a distribution kernel. Linux distributions tend to ship broad hardware and protocol support, especially in general-purpose kernels. A feature can be obscure, lightly used, and still available enough to be part of the risk conversation.
The modern kernel is full of these half-visible surfaces. They are not “legacy” in the sense of being dead, and they are not “mainstream” in the sense of being in every dashboard. They sit between those categories: maintained, useful to a minority, compiled into or packaged alongside general systems, and often autoloadable when a sufficiently specific code path is exercised.
For desktop Linux users, this may sound distant. For enterprise administrators, it should sound familiar. The same dynamic appears in filesystem drivers, tunneling modules, packet classifiers, compatibility layers, and crypto helpers. You do not have to use a feature every day for it to be part of your patch-management problem.
The Patch Is Really About Kernel Manners Under Hostile Input
The fix for CVE-2026-46085 is not conceptually complicated. The packet length passed to the crypto implementation must be aligned to the algorithm’s expectations, so the patch prevents a misaligned length from reaching that layer. If decryption fails for reasons other than memory exhaustion, the call is aborted as a protocol error rather than letting the failure path drift ambiguously upward.That is classic defensive kernel programming: sanitize before delegation, distinguish resource failure from malformed input, and avoid turning diagnostics into reachable behavior. The best kernel patches often read this way. They are less about a single dramatic exploit primitive than about closing the gap between “this should never happen” and “the network is allowed to send nonsense.”
The removed warning is especially important because warning paths have a history of becoming nuisance vulnerabilities. A remotely triggerable warning can fill logs, trip monitoring, degrade confidence in a system, or in some configurations contribute to denial-of-service-like behavior. Even when it is not memory corruption, it is still externally induced kernel distress.
There is also a subtle cultural shift here. Older kernel code often treated impossible states as programmer errors. Modern exposed subsystems have to treat many impossible states as attacker-controlled inputs. CVE-2026-46085 is a reminder that the boundary between those worlds is not determined by developer intent; it is determined by reachability.
The NVD Gap Leaves Administrators With the Hard Part
NVD’s record for CVE-2026-46085 is currently marked as awaiting enrichment, with no CVSS 4.0, 3.x, or 2.0 score supplied by NIST. That is normal for fresh kernel CVEs, but it creates an uncomfortable window for administrators who rely on scoring pipelines to prioritize action. The vulnerability exists, the patch exists, but the spreadsheet cell that tells procurement and compliance how worried to be is blank.This is where Linux kernel security often diverges from application security. A web application CVE may arrive with a crisp exploit narrative: unauthenticated remote code execution, fixed in version X, exploited in the wild. Kernel CVEs frequently land as patch-derived records with terse descriptions and several stable backport commits. The people who know how serious they are may need to inspect code paths, configs, module loading, and distribution packaging.
For CVE-2026-46085, the practical first question is whether a system has AF_RXRPC and RXKAD support available and whether anything uses it. That cannot be answered by the CVE record alone. It depends on the distribution kernel, configuration choices, installed modules, workload behavior, and whether AFS or other RxRPC consumers are in play.
The lack of a score should therefore push teams toward inventory, not complacency. A low-profile kernel bug in an unused module may be a routine patch. The same bug in a reachable service path on a multi-user or network-facing host is a different operational matter. CVSS will eventually simplify the conversation, but it will not replace local context.
Dirty Frag Changed the Background Noise Around RxRPC
CVE-2026-46085 does not arrive in a vacuum. In recent weeks, RxRPC has been part of the broader Linux kernel security conversation because of Dirty Frag reporting, where RxRPC and IPsec-related paths were discussed as part of local privilege escalation chains. CVE-2026-46085 is a different issue, but it lands while administrators are already rechecking whether RxRPC is present, loadable, or worth disabling.That background matters because security teams do not triage vulnerabilities as isolated dictionary entries. They triage them amid patterns. When a niche subsystem appears in multiple advisories, patch discussions, and mitigations within a short window, it becomes a risk cluster even if each individual CVE has a distinct root cause.
This is also why “we do not use AFS” is not always the end of the conversation. It may be true, and it may lower exposure substantially. But administrators still need to know whether the module can be loaded, whether unprivileged users can trigger relevant paths, whether containers can reach the needed interfaces, and whether distribution hardening already blocks the risky route.
There is a temptation to overcorrect here. Not every RxRPC bug means every Linux host is in imminent danger. But the opposite error is more common in enterprise estates: assuming that obscure equals absent. The last few years of kernel security have repeatedly punished that assumption.
Windows Shops Should Still Pay Attention
At first glance, a Linux kernel RxRPC CVE may seem out of place for a WindowsForum audience. But most Windows environments are no longer Windows-only environments. They run Linux appliances, WSL developer machines, Kubernetes nodes, storage gateways, VPN concentrators, CI runners, identity services, and cloud images that rarely show up in the same asset view as domain controllers and Windows endpoints.That mixed estate is where bugs like CVE-2026-46085 become easy to mishandle. The Windows patch routine may be mature, calendarized, and reported. The Linux kernel routine may be fragmented among platform teams, DevOps owners, appliance vendors, and cloud image maintainers. A vulnerability in a niche kernel subsystem can fall between those ownership models.
WSL deserves a careful mention, not because this CVE is known to be a WSL-specific threat, but because WSL has normalized Linux kernels on Windows-managed endpoints. Security teams that once thought of Linux as “server-side” now have developer workstations running Linux userlands and kernel integrations as part of daily workflows. Whether RxRPC is present or reachable in a given WSL kernel is a technical inventory question, not a branding question.
The more important point is governance. If your vulnerability process treats Linux kernel CVEs as someone else’s problem until there is a branded exploit, you are late by design. CVE-2026-46085 is precisely the sort of quiet kernel maintenance item that tests whether cross-platform patching is real or merely aspirational.
The Remote Warning Removal Is a Security Story in Miniature
The phrase “remove theWARN_ON_ONCE() so that it can’t be remotely triggered” deserves more attention than it will get. It is a concise description of a kernel hardening philosophy: production systems should not expose developer assertions to untrusted traffic. The trace line can remain because observability is useful. The warning goes because externally induced kernel warnings are bad interface design.There is a difference between logging a malformed packet and letting that packet trip a kernel warning macro. The former is a controlled administrative signal. The latter is a sign that an internal assumption escaped into the threat model. Attackers love those seams because they often reveal where code was written for correctness under friendly conditions rather than resilience under hostile ones.
This distinction is not unique to Linux. Windows administrators have seen the same pattern in event log floods, driver assertion failures, and crash-prone parsing paths. The platform differs, but the lesson is universal: diagnostics that are safe in a lab can become liabilities when reachable from a network boundary.
CVE-2026-46085 is therefore not only about crypto length alignment. It is about the discipline of making the kernel boring under malformed input. Boring is a virtue. Boring means reject, trace, and continue.
Stable Backports Are the Real Fix, Not the CVE Page
The CVE record lists multiple stable kernel references, which is typical for fixes propagated across maintained branches. That is where administrators should focus. The actionable artifact is not the NVD entry; it is the patched kernel package that your distribution or appliance vendor ships after incorporating the relevant upstream stable commit.For source builders and distribution maintainers, the commit message is clear enough: the rxkad packet verification path needed to prevent misaligned crypto lengths, abort on non-ENOMEM decrypt errors, and stop emitting a remotely triggerable warning. For everyone else, the job is less glamorous. Find the vendor advisory, identify the kernel build that contains the fix, roll it through test, and reboot systems that need a new kernel in memory.
That reboot requirement is still one of Linux’s operational pain points. Live patching can help in some environments, but network-stack fixes in modular or complex paths often still lead administrators back to the old truth: the patched package is not the same as the running kernel. Inventory tools should report both installed and active versions.
This is where compliance dashboards can lie by omission. A server may show an updated kernel package and still be running the vulnerable one until reboot. A golden image may be patched while long-lived instances are not. A container host may be rebuilt while developer laptops lag for weeks. Kernel CVEs reward operational precision.
Mitigation Is Possible, but It Is Not a Substitute for Knowing Your Estate
For systems that do not need RxRPC, disabling or preventing the relevant module from loading can be a reasonable temporary mitigation, depending on distribution support and local policy. But mitigation by module blocking is not a magic eraser. It can break AFS use cases, surprise legacy workflows, and create drift if left behind after patching.Administrators should also avoid cargo-culting mitigations from adjacent vulnerabilities. Dirty Frag discussions often mentioned RxRPC alongside IPsec modules, but CVE-2026-46085 is its own issue with its own fix. If you disable a module, do it because your exposure analysis says the feature is unnecessary, not because a social post bundled several scary names together.
The cleanest path remains boring: patch the kernel through the distribution’s supported channel. If immediate patching is not possible, then module policy, workload isolation, and network exposure reduction can buy time. But those measures should be tracked as exceptions, not treated as permanent architecture.
In mature environments, this becomes a configuration-management problem. If RxRPC is not approved anywhere, enforce that as policy. If it is approved only for AFS clients, scope it to those hosts and monitor accordingly. If nobody knows, CVE-2026-46085 is a useful excuse to find out.
The Bigger Pattern Is Parser Fragility at Kernel Speed
The most revealing phrase in the vulnerability description is “misaligned crypto length.” It sounds like plumbing, and it is. But kernel vulnerabilities often begin as plumbing mistakes: a length rounded incorrectly, an error code treated too casually, a buffer interpreted before validation, a diagnostic left in the wrong place.Network-facing kernel code is particularly unforgiving because packets are hostile by default. The kernel has to parse, authenticate, decrypt, route, and account for data at speed. Every optimization and every assumption is under pressure. Crypto adds another layer, because algorithms often expect block sizes, alignment, padding, and failure semantics to be respected exactly.
Rxkad is especially emblematic because it sits at the intersection of old protocol assumptions and modern hardening expectations. Kerberos-derived AFS security code was not born in today’s threat climate of cloud multi-tenancy, container escape research, and automated exploit diffing. The code can be maintained and still carry design assumptions that need periodic tightening.
That is not an indictment of Linux. It is the reality of all long-lived operating systems. Windows has decades-old subsystems with modern patch trains; Linux has protocol modules that matter to small but real user bases; BSDs have their own inherited surfaces. Security engineering is increasingly the art of making old interfaces survive new adversaries.
The Patch Notes Tell Administrators Exactly Where to Look
The practical response to CVE-2026-46085 should be concrete rather than dramatic. The vulnerability is fresh, not fully scored by NVD, and tied to a specific Linux kernel subsystem. That combination calls for targeted inventory and routine urgency, not panic.- Administrators should identify systems with AF_RXRPC and RXKAD support available, especially hosts that use AFS or carry broad general-purpose distribution kernels.
- Kernel updates should be tracked by running version, not merely by installed package, because the fix is not active until the patched kernel is actually booted.
- Systems that do not require RxRPC can consider blocking the module as a temporary control, but that decision should be documented and revisited after patching.
- Security teams should not wait for NVD scoring before beginning exposure analysis, because the upstream fix and CVE publication already establish that the bug is real.
- Mixed Windows and Linux estates should route this through the same vulnerability governance process used for higher-profile platform issues, rather than leaving it to informal Linux owner judgment.
- Monitoring should treat repeated RxRPC aborts or malformed packet traces as useful signals, especially on systems where RxRPC is not expected to be in use.
CVE Scoring Will Arrive After the Operational Decision
When NVD eventually enriches CVE-2026-46085, many organizations will get the severity label they were waiting for. That label will help with reporting, but it will arrive after the most important work should have started. The right question today is not “what color is the CVSS badge?” It is “where could this code run in our environment, and how quickly can we move to a fixed kernel?”This is the recurring frustration of kernel security in 2026. The industry has built enormous machinery around vulnerability identifiers, but the identifiers are often thinner than the patches that caused them. A terse commit message may carry more operational truth than the polished database entry that appears later.
CVE-2026-46085 also shows why sysadmins should read vulnerability descriptions with an engineer’s suspicion. “Misaligned crypto length” is not flashy, but it tells you the bug is in packet handling, crypto boundaries, and error behavior. “Remotely triggered warning” tells you the input path is reachable enough to matter. “Awaiting enrichment” tells you the public scoring process has not caught up.
That is enough to act. Not to overreact, not to declare an internet-wide emergency, but to patch with discipline and verify with evidence. The quiet CVEs are often the ones that reveal whether a security program is driven by risk or by headlines.
The forward-looking lesson is that Linux administrators, Windows administrators, and the many people now responsible for both need to treat obscure kernel subsystems as first-class inventory items. CVE-2026-46085 will likely disappear into the next stable kernel rollup for many users, which is exactly what should happen. But the pattern will return: a small parser flaw, a niche module, a missing score, a patch that says more than the advisory. The organizations that handle those calmly now will be better prepared when the next quiet kernel corner becomes the loudest part of the incident channel.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:03:24-07:00
NVD - CVE-2026-46085
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:03:24-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: wiz.io
Dirty Frag (CVE-2026-43284) Linux Privilege Escalation | Wiz Blog
Technical breakdown of Dirty Frag/CopyFail2 (CVE-2026-43284), a Linux LPE affecting major Linux distros. Learn what's affected and how to protect your systems.
www.wiz.io
- Related coverage: spinics.net
[PATCH net 0/4] rxrpc: Miscellaneous fixes — Linux Kernel
Linux Kernel: [PATCH net 0/4] rxrpc: Miscellaneous fixes
www.spinics.net
- Related coverage: mirror.iscas.ac.cn
- Related coverage: sysdig.com
Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC | Sysdig
Dirty Frag (CVE-2026-43284, CVE-2026-43500) exposes a critical Linux kernel flaw enabling local privilege escalation to root. Learn how it works, affected systems, detection with Sysdig and Falco, and mitigation strategies.
www.sysdig.com
- Related coverage: corgea.com
Dirty Frag: Linux kernel ESP and RxRPC flaws enable local root escalation | Corgea
Dirty Frag chains CVE-2026-43284 in Linux kernel ESP/IPsec handling with CVE-2026-43500 in RxRPC to turn local access into root on many Linux distributions, with public proof-of-concept code available before broad vendor patch coverage.
corgea.com
- Related coverage: patchsiren.com
CVE-2026-43500: Linux rxrpc packet-handling bug can corrupt kernel memory
Linux kernel CVE-2026-43500 affects rxrpc packet handling on local attack paths. Patch affected kernels before 6.18.29 and 7.0.6, and verify vendor backports.
patchsiren.com
- Related coverage: mail-archive.com
[PATCH net 0/2] rxrpc: Fix a warning and a leak [ver #2]
www.mail-archive.com
- Related coverage: labs.cloudsecurityalliance.org
- Related coverage: docs.kernel.org
RxRPC Network Protocol — The Linux Kernel documentation
docs.kernel.org
- Related coverage: kernel.org
RxRPC Network Protocol — The Linux Kernel documentation
www.kernel.org
- Related coverage: linux.googlesource.com
- Related coverage: sources.debian.org
File: afs.rst | Debian Sources
sources.debian.org
- Related coverage: cateee.net
- Related coverage: android.googlesource.com
- Related coverage: kernel-doc.readthedocs.io
