CVE-2026-43502 is a newly published Linux kernel vulnerability, added to NVD on May 21, 2026, involving Reliable Datagram Sockets zerocopy send cleanup when pinned user pages are released before a message reaches the socket queue. The bug is not a Windows Remote Desktop Services issue, despite the overloaded “RDS” acronym. It is a kernel networking lifetime bug, and its practical importance lies less in its headline severity than in what it says about modern high-performance I/O paths: the faster the kernel tries to move data, the more dangerous cleanup bookkeeping becomes.
At first glance, CVE-2026-43502 looks like the kind of entry that makes vulnerability scanners nervous and humans sleepy. There is no NVD CVSS score yet, no public exploit chain attached to the record, and the description reads like a kernel developer explaining why a pointer must be captured before a spinlock-protected cleanup path changes state.
But that is exactly why it matters. Kernel vulnerabilities often do not begin as cinematic buffer overflows or remote-code-execution fireworks. They begin as ownership confusion: one subsystem believes an object belongs to one lifecycle, another subsystem treats it as if it belongs to a different lifecycle, and an error path turns a rare timing window into memory corruption, accounting drift, or a use-after-free class of problem.
This CVE concerns Linux RDS, short for Reliable Datagram Sockets, a networking protocol originally associated with high-throughput clustered and database environments. It also concerns zerocopy send, a performance optimization designed to avoid unnecessary memory copying by pinning user pages and letting the kernel transmit from them directly. The bug appears in the awkward space between those two ideas: a send operation has pinned memory, but the message has not yet been attached to the sending socket.
That gap is the vulnerability.
That distinction is not pedantry. Security operations teams routinely triage CVEs under time pressure, and acronym collisions can waste hours. A scanner report that says “RDS vulnerability” could point to a Linux kernel module, an AWS database service, a Windows terminal server role, or a completely unrelated product family depending on the context.
Here, the affected code lives in the Linux kernel. Windows clients, Windows Server Remote Desktop Session Hosts, and Azure Virtual Desktop deployments are not directly implicated by this CVE. Mixed estates may still care, especially where Linux appliances, storage systems, database nodes, containers, or hypervisor hosts run kernels that include RDS support.
The right operational question is therefore not “Are our Remote Desktop servers exposed?” It is “Do any Linux systems we run ship or enable the RDS kernel code path, and have our vendors incorporated the relevant stable kernel fix?”
The tradeoff is bookkeeping. Once user pages are pinned, somebody has to remember that they are pinned, somebody has to account for them, and somebody has to release them exactly once when the send operation is complete or abandoned. That “exactly once” requirement is unforgiving.
CVE-2026-43502 lives in the failure path. A zerocopy send can fail after user pages have already been pinned but before the RDS message has been queued on the sending socket. The old cleanup path inferred zerocopy state partly from whether the message was associated with a socket. That assumption was wrong for the early-failure case.
The fix changes the discriminator. Instead of using socket association as the deciding signal, the purge path captures the zerocopy notifier up front and treats its presence as the evidence that zerocopy cleanup rules apply. If the message is already associated with a socket, the normal completion path remains. If it is not, the kernel directly drops the pinned-page accounting and releases the notifier before putting the payload pages.
That is a narrow patch. It is also the kind of narrow patch that prevents rare error paths from becoming security incidents.
In this case, the ordinary queued send lifecycle was not the problem. Once an RDS message was attached to the sending socket, the existing zerocopy completion path could do its work. The trouble was a message that had gone far enough to pin user pages but not far enough to acquire the socket relationship the cleanup code expected.
That is a classic kernel lifetime bug. The object is real enough to need cleanup, but not “real” enough to have reached the state the cleanup routine uses to infer ownership. The previous code effectively asked, “Is this message associated with a socket?” when the safer question was, “Does this message have a zerocopy notifier that proves pinned-page ownership exists?”
The patch’s answer is to capture
This is not glamorous engineering, but it is security engineering. The kernel is full of state machines, and vulnerabilities emerge when cleanup logic uses a proxy for state instead of the state itself.
This lag is common for newly published kernel CVEs. The Linux kernel community now assigns CVEs to many fixes that previously might have appeared only as stable-tree commits or mailing-list patches. That improves traceability, but it also creates a wave of records whose exploitability, affected configurations, and vendor-specific impact need downstream analysis.
The absence of a score should push administrators toward context, not complacency. Is RDS compiled into the kernel? Is the module present? Can unprivileged users reach the relevant send path? Are containers able to create or interact with the protocol family? Does the system run a vendor kernel that backports fixes without changing the visible upstream version?
Those are better questions than waiting for a single number. CVSS can help prioritize, but it cannot replace understanding whether a particular code path exists in your estate.
It is good because kernel.org-originated CVE records make it easier to connect a stable patch to a vulnerability ID. That matters for auditors, vulnerability scanners, SBOM workflows, and enterprise patch governance. A fix buried in a Git commit is not enough for many organizations; they need an identifier their tooling understands.
It is exhausting because not every kernel CVE has the same operational urgency. Some affect obscure drivers. Some require exotic hardware. Some are reachable only with local privileges and a particular configuration. Others are terrifying. The CVE format flattens those distinctions until human analysis restores them.
CVE-2026-43502 sits in the middle. It is not a headline-grabbing remote worm candidate based on the public description. But it touches memory lifetime, pinned pages, and networking code, which are all areas where small mistakes can have outsized consequences. The practical response is measured patching, not panic.
This is where admins must be careful with version checking. A Red Hat, Ubuntu, Debian, SUSE, Oracle, or appliance vendor kernel may report a version that appears older than the upstream fixed version while still containing the backported patch. Conversely, a custom kernel may report a new-looking version while lacking a particular stable commit if it was built from an unusual tree.
The remediation path is therefore vendor-specific. For general-purpose Linux servers, apply the vendor’s kernel security update when available and reboot into the fixed kernel. For appliances and storage systems, wait for the vendor advisory rather than assuming upstream commit hashes map neatly onto the device firmware. For custom kernels, inspect whether the RDS fix has been applied to
The reboot is the part no one likes. Kernel fixes generally do not matter until the fixed kernel is running. Live patching may cover some environments, but networking memory-management fixes are not something to assume into existence.
That narrows the exposure. It does not eliminate it.
Attack surface in the Linux kernel is often configuration-dependent. A module that is not loaded today might be loadable tomorrow. A container host might expose more networking functionality than intended. A distribution might compile support differently from another. A high-performance database stack might enable code paths an ordinary web server never touches.
There is also the local-versus-remote ambiguity. The public CVE text describes a send path involving user pages, which suggests an attacker would need the ability to initiate the relevant RDS zerocopy operation from a local context or a context with access to the socket interface. That is not the same as a remote unauthenticated packet hitting a listening service. But local kernel bugs are still important, particularly on multi-user systems, container hosts, shared compute platforms, and any environment where privilege boundaries matter.
Until vendors publish more detailed advisories or exploitability analysis, the defensible position is conservative: treat this as a kernel memory-lifetime bug in a specialized networking path, prioritize systems where RDS is available or used, and avoid overstating either the danger or the safety.
The reason is simple: cleanup paths encode ownership. They decide which reference counts are decremented, which pages are unpinned, which callbacks fire, which socket references are released, and which memory objects are freed. If cleanup code guesses wrong, the bug may manifest as a leak, a double release, a stale pointer, or corrupted accounting.
In CVE-2026-43502, the key conceptual fix is not large. The code now recognizes that zerocopy ownership is determined by the notifier, not by whether the message has reached the socket queue. That sentence is almost boring, but it is the whole security story.
The patch also preserves the normal queued completion path. That restraint matters. Kernel fixes that disturb the fast path can create regressions, especially in networking. Here the developers appear to have targeted the early-failure case without rewriting the successful send lifecycle.
That is the best kind of stable fix: small, specific, and based on a corrected ownership model.
Windows environments routinely include Linux in places that are not always visible to traditional endpoint inventories. WSL runs Linux userlands on developer machines. Hyper-V hosts Linux guests. Kubernetes clusters mix Windows and Linux nodes. Security appliances, backup systems, storage gateways, monitoring collectors, and CI/CD runners often run Linux under the hood. Cloud environments add managed images, container base layers, and marketplace appliances into the mix.
CVE-2026-43502 is not a Windows vulnerability, but Windows administrators may still own systems affected by it. The relevant boundary is not operating-system tribalism. It is asset ownership.
This is especially true for organizations that inventory “servers” well but inventory “infrastructure appliances” poorly. If a product embeds a Linux kernel and exposes high-performance networking features, the vendor’s patch cadence becomes part of your security posture. That is where many CVEs linger: not on the obvious Linux VM, but inside the box no one wants to reboot.
The second task is to map vendor coverage. Distribution security trackers may lag the NVD publication by hours or days, and enterprise kernels may receive backports under package revision numbers rather than obvious upstream version jumps. Do not assume that “not mentioned yet” means “not affected,” but also do not assume every upstream CVE maps cleanly to every distribution kernel.
The third task is reboot planning. Kernel updates are still operational events. Even with kexec, live patching, HA pairs, and rolling cluster maintenance, production estates need sequencing. The right priority is usually internet-facing or multi-tenant Linux first, specialized clustered workloads next, and low-risk single-purpose systems according to maintenance windows.
Finally, record the exception logic. If a scanner flags CVE-2026-43502 on a system where RDS is not compiled, not present, or not loadable, document that. If a vendor says a product is not affected because the code path is disabled, keep the advisory. Six months from now, that paper trail will matter more than anyone’s memory.
The fix also illustrates a useful rule for reading kernel security patches: look for the state variable the patch elevates. Here, the notifier becomes the authoritative signal for zerocopy ownership. That tells us the prior model was too indirect and that the bug was not merely a missing null check, but a mismatch between object lifetime and cleanup inference.
For defenders, that is useful because it points toward affected scenarios. Bugs like this tend to matter where the relevant feature can be invoked and where memory lifetime mistakes can cross privilege boundaries. They are less relevant where the subsystem is absent. They are more relevant where untrusted users, containers, or workloads can exercise specialized networking syscalls.
The CVE record’s plain language says the normal queued completion path is unchanged. That is reassuring in one narrow sense: the fix aims at an early send failure, not the entire RDS transmit model. But early failure paths are reachable precisely because real systems run out of memory, hit limits, race state transitions, and receive malformed or unexpected input sequences.
Security is not only about what happens when everything works. It is about what happens when something fails halfway.
The concrete takeaways are refreshingly specific:
A Small Cleanup Bug With a Large Kernel Lesson
At first glance, CVE-2026-43502 looks like the kind of entry that makes vulnerability scanners nervous and humans sleepy. There is no NVD CVSS score yet, no public exploit chain attached to the record, and the description reads like a kernel developer explaining why a pointer must be captured before a spinlock-protected cleanup path changes state.But that is exactly why it matters. Kernel vulnerabilities often do not begin as cinematic buffer overflows or remote-code-execution fireworks. They begin as ownership confusion: one subsystem believes an object belongs to one lifecycle, another subsystem treats it as if it belongs to a different lifecycle, and an error path turns a rare timing window into memory corruption, accounting drift, or a use-after-free class of problem.
This CVE concerns Linux RDS, short for Reliable Datagram Sockets, a networking protocol originally associated with high-throughput clustered and database environments. It also concerns zerocopy send, a performance optimization designed to avoid unnecessary memory copying by pinning user pages and letting the kernel transmit from them directly. The bug appears in the awkward space between those two ideas: a send operation has pinned memory, but the message has not yet been attached to the sending socket.
That gap is the vulnerability.
RDS Is Not Remote Desktop Services, and That Distinction Matters
For WindowsForum readers, the first trap is the acronym. “RDS” usually means Remote Desktop Services in a Windows Server conversation. In this CVE, it means Linux Reliable Datagram Sockets, a kernel networking facility undernet/rds, not Microsoft’s session-host stack, not RDP, and not anything patched through Windows Update.That distinction is not pedantry. Security operations teams routinely triage CVEs under time pressure, and acronym collisions can waste hours. A scanner report that says “RDS vulnerability” could point to a Linux kernel module, an AWS database service, a Windows terminal server role, or a completely unrelated product family depending on the context.
Here, the affected code lives in the Linux kernel. Windows clients, Windows Server Remote Desktop Session Hosts, and Azure Virtual Desktop deployments are not directly implicated by this CVE. Mixed estates may still care, especially where Linux appliances, storage systems, database nodes, containers, or hypervisor hosts run kernels that include RDS support.
The right operational question is therefore not “Are our Remote Desktop servers exposed?” It is “Do any Linux systems we run ship or enable the RDS kernel code path, and have our vendors incorporated the relevant stable kernel fix?”
Zerocopy Is Fast Because It Borrows Trust From Memory Management
Zerocopy networking is one of those optimizations that sounds simple until it breaks. Instead of copying user data into kernel buffers before transmission, the kernel can pin the relevant user-space pages and arrange for the network stack to transmit from them. This saves CPU cycles and memory bandwidth, which matters in high-throughput workloads.The tradeoff is bookkeeping. Once user pages are pinned, somebody has to remember that they are pinned, somebody has to account for them, and somebody has to release them exactly once when the send operation is complete or abandoned. That “exactly once” requirement is unforgiving.
CVE-2026-43502 lives in the failure path. A zerocopy send can fail after user pages have already been pinned but before the RDS message has been queued on the sending socket. The old cleanup path inferred zerocopy state partly from whether the message was associated with a socket. That assumption was wrong for the early-failure case.
The fix changes the discriminator. Instead of using socket association as the deciding signal, the purge path captures the zerocopy notifier up front and treats its presence as the evidence that zerocopy cleanup rules apply. If the message is already associated with a socket, the normal completion path remains. If it is not, the kernel directly drops the pinned-page accounting and releases the notifier before putting the payload pages.
That is a narrow patch. It is also the kind of narrow patch that prevents rare error paths from becoming security incidents.
The Bug Sits in the Error Path, Which Is Where Kernel Assumptions Go to Die
Normal paths get exercised constantly. Error paths are where assumptions fossilize.In this case, the ordinary queued send lifecycle was not the problem. Once an RDS message was attached to the sending socket, the existing zerocopy completion path could do its work. The trouble was a message that had gone far enough to pin user pages but not far enough to acquire the socket relationship the cleanup code expected.
That is a classic kernel lifetime bug. The object is real enough to need cleanup, but not “real” enough to have reached the state the cleanup routine uses to infer ownership. The previous code effectively asked, “Is this message associated with a socket?” when the safer question was, “Does this message have a zerocopy notifier that proves pinned-page ownership exists?”
The patch’s answer is to capture
op_mmp_znotifier at the beginning of rds_message_purge() and clear it under lock. That makes the cleanup decision explicit. It also reduces the chance that later code will observe stale state or attempt the wrong cleanup routine.This is not glamorous engineering, but it is security engineering. The kernel is full of state machines, and vulnerabilities emerge when cleanup logic uses a proxy for state instead of the state itself.
The Missing CVSS Score Should Not Be Misread as Safety
As of publication, NVD lists no CVSS 4.0, 3.x, or 2.0 score for CVE-2026-43502. That does not mean the vulnerability is harmless. It means NVD enrichment has not yet assigned a severity vector.This lag is common for newly published kernel CVEs. The Linux kernel community now assigns CVEs to many fixes that previously might have appeared only as stable-tree commits or mailing-list patches. That improves traceability, but it also creates a wave of records whose exploitability, affected configurations, and vendor-specific impact need downstream analysis.
The absence of a score should push administrators toward context, not complacency. Is RDS compiled into the kernel? Is the module present? Can unprivileged users reach the relevant send path? Are containers able to create or interact with the protocol family? Does the system run a vendor kernel that backports fixes without changing the visible upstream version?
Those are better questions than waiting for a single number. CVSS can help prioritize, but it cannot replace understanding whether a particular code path exists in your estate.
Linux Kernel CVEs Are Becoming More Transparent and More Noisy
This record is part of a broader shift in Linux vulnerability handling. Kernel fixes are increasingly mapped to CVEs in a more systematic way, including bugs that look like ordinary correctness fixes until viewed through a security lens. For defenders, that is both good and exhausting.It is good because kernel.org-originated CVE records make it easier to connect a stable patch to a vulnerability ID. That matters for auditors, vulnerability scanners, SBOM workflows, and enterprise patch governance. A fix buried in a Git commit is not enough for many organizations; they need an identifier their tooling understands.
It is exhausting because not every kernel CVE has the same operational urgency. Some affect obscure drivers. Some require exotic hardware. Some are reachable only with local privileges and a particular configuration. Others are terrifying. The CVE format flattens those distinctions until human analysis restores them.
CVE-2026-43502 sits in the middle. It is not a headline-grabbing remote worm candidate based on the public description. But it touches memory lifetime, pinned pages, and networking code, which are all areas where small mistakes can have outsized consequences. The practical response is measured patching, not panic.
Stable Kernel Backports Are the Real Remediation Story
The NVD record points to multiple stable kernel commits, which is usually a sign that the fix has been carried into several maintained kernel branches. That matters more than the mainline commit alone. Most production Linux systems do not run pristine upstream kernels; they run distribution or vendor kernels with backported patches.This is where admins must be careful with version checking. A Red Hat, Ubuntu, Debian, SUSE, Oracle, or appliance vendor kernel may report a version that appears older than the upstream fixed version while still containing the backported patch. Conversely, a custom kernel may report a new-looking version while lacking a particular stable commit if it was built from an unusual tree.
The remediation path is therefore vendor-specific. For general-purpose Linux servers, apply the vendor’s kernel security update when available and reboot into the fixed kernel. For appliances and storage systems, wait for the vendor advisory rather than assuming upstream commit hashes map neatly onto the device firmware. For custom kernels, inspect whether the RDS fix has been applied to
net/rds/message.c.The reboot is the part no one likes. Kernel fixes generally do not matter until the fixed kernel is running. Live patching may cover some environments, but networking memory-management fixes are not something to assume into existence.
The Attack Surface Is Probably Narrow, but Narrow Is Not the Same as Irrelevant
Reliable Datagram Sockets is not a default application protocol most WindowsForum readers will encounter every day. It is historically associated with clustered systems and specialized networking workloads, including database-related environments. Many Linux systems may have the code available only as a module, and many will never load it.That narrows the exposure. It does not eliminate it.
Attack surface in the Linux kernel is often configuration-dependent. A module that is not loaded today might be loadable tomorrow. A container host might expose more networking functionality than intended. A distribution might compile support differently from another. A high-performance database stack might enable code paths an ordinary web server never touches.
There is also the local-versus-remote ambiguity. The public CVE text describes a send path involving user pages, which suggests an attacker would need the ability to initiate the relevant RDS zerocopy operation from a local context or a context with access to the socket interface. That is not the same as a remote unauthenticated packet hitting a listening service. But local kernel bugs are still important, particularly on multi-user systems, container hosts, shared compute platforms, and any environment where privilege boundaries matter.
Until vendors publish more detailed advisories or exploitability analysis, the defensible position is conservative: treat this as a kernel memory-lifetime bug in a specialized networking path, prioritize systems where RDS is available or used, and avoid overstating either the danger or the safety.
The Fix Shows Why “Cleanup” Code Deserves Security Review
Security coverage often gravitates toward input parsing, authentication, and cryptography. Cleanup code rarely gets the same attention, yet cleanup mistakes are a recurring source of kernel vulnerabilities.The reason is simple: cleanup paths encode ownership. They decide which reference counts are decremented, which pages are unpinned, which callbacks fire, which socket references are released, and which memory objects are freed. If cleanup code guesses wrong, the bug may manifest as a leak, a double release, a stale pointer, or corrupted accounting.
In CVE-2026-43502, the key conceptual fix is not large. The code now recognizes that zerocopy ownership is determined by the notifier, not by whether the message has reached the socket queue. That sentence is almost boring, but it is the whole security story.
The patch also preserves the normal queued completion path. That restraint matters. Kernel fixes that disturb the fast path can create regressions, especially in networking. Here the developers appear to have targeted the early-failure case without rewriting the successful send lifecycle.
That is the best kind of stable fix: small, specific, and based on a corrected ownership model.
Windows Shops Still Need to Care Because Linux Is in the Windows Estate Now
A decade ago, a Linux kernel RDS CVE might have been easy for many Windows-centric admins to ignore. In 2026, that separation is less realistic.Windows environments routinely include Linux in places that are not always visible to traditional endpoint inventories. WSL runs Linux userlands on developer machines. Hyper-V hosts Linux guests. Kubernetes clusters mix Windows and Linux nodes. Security appliances, backup systems, storage gateways, monitoring collectors, and CI/CD runners often run Linux under the hood. Cloud environments add managed images, container base layers, and marketplace appliances into the mix.
CVE-2026-43502 is not a Windows vulnerability, but Windows administrators may still own systems affected by it. The relevant boundary is not operating-system tribalism. It is asset ownership.
This is especially true for organizations that inventory “servers” well but inventory “infrastructure appliances” poorly. If a product embeds a Linux kernel and exposes high-performance networking features, the vendor’s patch cadence becomes part of your security posture. That is where many CVEs linger: not on the obvious Linux VM, but inside the box no one wants to reboot.
The Practical Triage Starts With Kernel Capability, Not the CVE Feed
The first administrative task is to determine whether RDS is present and usable. On Linux systems, that typically means checking kernel configuration, loaded modules, and whether the relevant protocol support is exposed. If the module is absent and cannot be loaded, risk drops sharply. If it is present, loadable, or required by an application stack, patch priority rises.The second task is to map vendor coverage. Distribution security trackers may lag the NVD publication by hours or days, and enterprise kernels may receive backports under package revision numbers rather than obvious upstream version jumps. Do not assume that “not mentioned yet” means “not affected,” but also do not assume every upstream CVE maps cleanly to every distribution kernel.
The third task is reboot planning. Kernel updates are still operational events. Even with kexec, live patching, HA pairs, and rolling cluster maintenance, production estates need sequencing. The right priority is usually internet-facing or multi-tenant Linux first, specialized clustered workloads next, and low-risk single-purpose systems according to maintenance windows.
Finally, record the exception logic. If a scanner flags CVE-2026-43502 on a system where RDS is not compiled, not present, or not loadable, document that. If a vendor says a product is not affected because the code path is disabled, keep the advisory. Six months from now, that paper trail will matter more than anyone’s memory.
The Signal Hidden Inside This One-Line Kernel Fix
This CVE is a reminder that modern kernels are less like monoliths than crowded airports. Pages, sockets, notifiers, memory accounting, callbacks, and protocol-specific message structures all move through the system with different boarding passes. The vulnerability appears when one gate agent checks the wrong document.The fix also illustrates a useful rule for reading kernel security patches: look for the state variable the patch elevates. Here, the notifier becomes the authoritative signal for zerocopy ownership. That tells us the prior model was too indirect and that the bug was not merely a missing null check, but a mismatch between object lifetime and cleanup inference.
For defenders, that is useful because it points toward affected scenarios. Bugs like this tend to matter where the relevant feature can be invoked and where memory lifetime mistakes can cross privilege boundaries. They are less relevant where the subsystem is absent. They are more relevant where untrusted users, containers, or workloads can exercise specialized networking syscalls.
The CVE record’s plain language says the normal queued completion path is unchanged. That is reassuring in one narrow sense: the fix aims at an early send failure, not the entire RDS transmit model. But early failure paths are reachable precisely because real systems run out of memory, hit limits, race state transitions, and receive malformed or unexpected input sequences.
Security is not only about what happens when everything works. It is about what happens when something fails halfway.
This Is the Kernel Patch Administrators Should Not Overdramatize or Ignore
CVE-2026-43502 should land in the “patch deliberately” pile. It is not, based on the public record, a reason to tear through every Windows RDS deployment or declare a broad remote compromise event. It is also not a record to dismiss because NVD has not assigned a score yet.The concrete takeaways are refreshingly specific:
- This CVE affects the Linux kernel RDS networking code, not Microsoft Remote Desktop Services.
- The flaw involves zerocopy send cleanup after user pages are pinned but before the message is queued on a socket.
- The upstream fix changes cleanup logic so the zerocopy notifier, not socket association, determines the correct ownership path.
- Administrators should prioritize Linux systems where RDS is compiled, loadable, enabled, or required by clustered and high-performance workloads.
- Vendor kernel updates and backports matter more than raw upstream version numbers, so remediation should be tied to distribution or appliance advisories.
- Systems patched with a fixed kernel generally need to boot into that kernel before the vulnerability is actually remediated.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-22T01:01:50-07:00
NVD - CVE-2026-43502
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-22T01:01:50-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cve.imfht.com
CVE-2026-31494: net: macb: use the current queue number for stats
## Overview The Linux kernel `net: macb` driver contains an out-of-bounds write vulnerability in statistics memory. `gem_get_ethtool_stats()` copies statistics based on the maximum number of queues,
cve.imfht.com
- Related coverage: lore-kernel.gnuweeb.org
- Related coverage: knightli.com
CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring
A practical summary of CVE-2026-43494 / PinTheft: how a Linux RDS zerocopy reference-counting issue can combine with io_uring fixed buffers into a local privilege escalation chain, and how administrators can assess prerequisites, reduce exposure, and wait for distribution fixes.
www.knightli.com
