Kernel.org disclosed CVE-2026-45899 on May 27, 2026, for a Linux kernel ext4 bug in which a failed extent split can leave stale entries in the filesystem’s extent status tree. That sentence sounds narrow, and in one sense it is: this is not a flashy remote-code-execution headline or a consumer scare story. But it is exactly the kind of low-level storage defect that should make administrators pause, because modern infrastructure is built on layers that quietly assume the filesystem cache tells the truth.
The fix is almost comically plain: when ext4 cannot finish splitting an extent, the kernel should drop the potentially stale cache entries rather than return immediately and leave bad state behind. The lesson is less plain. Filesystem bugs do not need a logo, a worm, or a ransomware crew to matter; they matter because they sit below nearly every operational promise an IT team makes.
The affected code lives in ext4, still one of the default answers to the question, “What filesystem is this Linux system actually using?” It appears across distributions, cloud images, appliances, Android-derived systems, embedded devices, rescue environments, and many self-managed servers. Even Windows-heavy shops often encounter it through Linux virtual machines, WSL workflows, container hosts, backup targets, hypervisors, and storage appliances.
CVE-2026-45899 is currently marked as awaiting NVD enrichment, with no NIST CVSS score assigned as of publication. That matters because severity dashboards often treat “no score yet” as a kind of limbo. In practice, administrators should read this as not yet classified, not as not important.
The vulnerability description says the problem occurs when splitting an ext4 extent fails. Some extents may still be in the middle of processing, and a direct error return can leave stale extent entries in the extent status tree. The upstream remedy is to drop the remaining potentially stale extents when the split fails.
That is a terse kernel explanation, but it points to a familiar class of storage bugs: the authoritative on-disk metadata and the in-memory acceleration structures can drift apart under an error path. The filesystem may not be “corrupt” in the dramatic, unmountable sense. It may simply be making decisions with stale information, which is often how the worst debugging sessions begin.
But extents are not static. Files are appended, truncated, preallocated, punched full of holes, rewritten, journaled, and moved through error conditions that storage engineers would rather not see at 3 a.m. Splitting an extent is one of those ordinary but delicate operations: a previously continuous range must be divided so the filesystem can represent a changed portion accurately.
The extent status tree is an in-memory structure used to cache extent state. Like most caches, it exists to avoid expensive repeated work. Like all caches, it becomes dangerous when it preserves information that the rest of the system can no longer trust.
CVE-2026-45899 sits precisely at that seam. If an extent split fails, the cleanup must be just as careful as the successful path. The kernel patch says the previous logic could leave entries behind that were still being processed. That is the kind of bug that rarely produces a simple user-facing symptom, because the user-visible failure may happen later, somewhere else, under a workload that merely happens to step on the stale state.
That is especially true while NVD has not yet assigned a CVSS vector. A final score may eventually classify the issue as modest, or it may flag availability and integrity impacts more clearly. Until then, the prudent reading is operational: this is a kernel bug in a default-class filesystem, fixed upstream and backported across stable branches.
The absence of a score should not be confused with the absence of risk. CVSS is useful for triage, but storage-layer defects often cut across the categories that scoring systems flatten. If stale extent state can lead to incorrect behavior, the most immediate concern is usually data integrity or system stability, not an attacker popping a shell.
That does not make it uninteresting to security teams. Availability is a security property. So is integrity. A bug that can help produce a filesystem error, stale mapping, unexpected kernel warning, or data-handling anomaly belongs in the patch queue even if nobody has shown a polished exploit.
CVE-2026-45899 is a good test of that failure mode. It is not likely to dominate general technology news. It does not have the obvious urgency of an internet-facing remote exploit. Yet it affects a component that many systems depend on precisely because nobody wants to think about it.
The kernel.org references show fixes across multiple stable commits, which usually means the change has been carried into several maintained kernel lines rather than left only in the development tree. That is encouraging, but it also pushes the burden downstream. Most administrators do not run kernels directly from kernel.org; they run Ubuntu, Debian, Fedora, Red Hat Enterprise Linux, SUSE, Arch, Proxmox, TrueNAS-derived components, Android kernels, cloud-tuned kernels, or vendor-maintained appliance builds.
That distribution layer matters. A server can be “up to date” according to one package repository and still be waiting for a vendor’s kernel rebuild. A container can be patched in user space while the host kernel remains unchanged. A Windows laptop running WSL can have fully current Linux packages inside the distro while the relevant kernel behavior depends on Microsoft’s WSL kernel servicing path.
WSL is the obvious bridge. Developers using WSL may store project trees on Linux-backed filesystems and run build pipelines that stress metadata paths in ways ordinary desktop usage does not. The more important exposure, however, is usually server-side: Linux VMs in Hyper-V, Kubernetes nodes, CI runners, backup repositories, monitoring appliances, and cloud workloads that authenticate against Microsoft identity but boot a Linux kernel.
Ext4 also shows up in recovery and migration workflows. Administrators may mount Linux volumes from rescue images, clone disks between environments, or run forensic tooling against ext4 partitions. If the kernel doing that work has a filesystem bug, the fact that the surrounding estate is Windows-centric offers little comfort.
For WindowsForum.com readers, the practical point is not that every Windows admin must become an ext4 maintainer. It is that the boundary between Microsoft infrastructure and Linux plumbing has blurred. Active Directory, Entra ID, Hyper-V, Windows Server, Azure, WSL, and Linux guests often coexist in the same operational chain. A storage-layer bug in one link can become an outage in a place whose dashboard says “Windows.”
The interesting part of CVE-2026-45899 is that it lives in an error path. The normal path is often hammered by everyday testing. The failure path is where timing, allocation pressure, unusual workloads, and partial state combine. That is where caches are hardest to reason about.
A failed extent split is not supposed to be the common case. But robust filesystems are judged by what they do when the uncommon case happens. Returning an error is not enough if the function has already changed in-memory state. Cleanup must restore invariants, not just stop the current operation.
That is the engineering story behind the phrase “drop extent cache.” It is not a performance tweak masquerading as a vulnerability fix. It is a correctness fix: if the cache may now be stale, throw away the suspect knowledge and force the system to rebuild from safer ground.
Stale extent status entries are especially awkward because they are not the same thing as a blatantly damaged disk. Hardware diagnostics may pass. SMART counters may look fine. The storage array may insist everything is healthy. The application may retry and recover, leaving only a suspicious line in the logs.
This is why kernel patching cannot be reduced to exploit-chasing. The bugs that cost the most operational time are often the ones that create ambiguity. Is it the SSD? The hypervisor? The guest kernel? The filesystem? The database? The backup tool? The answer may be a narrow ext4 error path that only shows up when a write pattern meets a failure condition.
In that sense, CVE-2026-45899 is less a standalone drama than a reminder of how many systems depend on silent correctness. When the filesystem cache is right, nobody notices. When it is wrong, every layer above it becomes a suspect.
But backported is not the same as deployed. Enterprise Linux users live behind vendor kernels. Cloud users live behind image pipelines and managed node pools. Appliance users live behind firmware bundles. Developers live behind whatever kernel their laptop, WSL installation, or distro channel happens to ship.
Administrators should therefore resist the easy question, “Is this fixed in Linux?” The better question is, “Is this fixed in the kernel I am actually booting?” That means checking distribution advisories, package changelogs, kernel build numbers, and vendor notices rather than relying on the existence of an upstream commit.
This distinction matters even more for long-term-support kernels. Stable trees receive many fixes, but organizations often pin kernels for hardware certification, driver compatibility, or change-control reasons. A storage fix can sit available for weeks while production remains deliberately frozen.
The right response is disciplined patch management. Identify systems using ext4. Determine which kernel versions and vendor builds contain the fix. Prioritize machines with heavy write workloads, virtualization hosts, CI infrastructure, storage-heavy services, and systems where filesystem inconsistency would be expensive to diagnose.
For production Linux servers, this will usually mean scheduling a kernel update and reboot through normal maintenance channels. For cloud and Kubernetes environments, it may mean rotating nodes rather than patching them in place. For WSL, it means watching Microsoft’s servicing of the WSL kernel rather than assuming the Linux userland distribution controls everything.
Backups deserve a special mention. Filesystem bugs are exactly why backups should be verified, not merely created. If a system has shown ext4 errors, odd I/O behavior, or unexplained data inconsistency, administrators should not treat patching as retroactive repair. Apply the fix, then validate the data and the recovery path.
Security tooling is only as useful as the metadata it consumes. If a vulnerability has no CVSS score, some systems under-rank it. If the affected product mapping is incomplete, asset scanners may miss it. If the description is technically dense, risk owners may not understand whether the issue matters in their environment.
This is where human judgment still earns its keep. A CVE in ext4 is not just a line item. It intersects with storage architecture, workload behavior, kernel maintenance, and recovery planning. A low-level bug with a limited trigger can still deserve prompt attention on systems that cannot tolerate filesystem weirdness.
The industry likes to pretend vulnerability management is a spreadsheet exercise. CVE-2026-45899 argues otherwise. The spreadsheet can tell you the record exists. It cannot tell you which of your aging Linux VMs hosts the one workload that will make a stale extent cache ruin your week.
Both views have merit. The flood of kernel CVEs can make prioritization harder, especially when many arrive without immediate severity scores. But the alternative is not a clean, perfectly curated universe. The alternative is a world where low-level fixes disappear into commit logs and only become “security” issues when someone later demonstrates a practical attack or outage.
For administrators, the answer is not to dismiss kernel CVEs wholesale. It is to build better filters. Filesystem, memory-management, networking, and privilege-boundary bugs should not be treated identically. A local-only bug on a single-purpose kiosk is not the same as a filesystem bug on a multi-tenant storage host.
CVE-2026-45899 is a useful example because it does not need to be sensational to be worth tracking. It is the kind of defect that rewards teams with good asset knowledge and punishes teams that manage kernels as an afterthought.
The second question is whether those systems receive kernel updates through a channel you control and monitor. A fleet managed by a modern configuration platform is one thing. A collection of vendor appliances, forgotten pet servers, and hand-built VMs is another.
The third question is what would happen if ext4 behaved incorrectly on those systems. A developer workstation may be inconvenient. A database host may be business-critical. A backup repository may be existentially important during an incident. Risk is not just vulnerability times exploitability; it is vulnerability times where the vulnerable thing sits.
This is where security and operations need to meet. Security teams can flag the CVE. Operations teams can identify the actual kernels and filesystems. Application owners can explain the cost of downtime or data inconsistency. Without all three, the organization is guessing.
The fix is almost comically plain: when ext4 cannot finish splitting an extent, the kernel should drop the potentially stale cache entries rather than return immediately and leave bad state behind. The lesson is less plain. Filesystem bugs do not need a logo, a worm, or a ransomware crew to matter; they matter because they sit below nearly every operational promise an IT team makes.
A Small ext4 Fix Lands in a Very Large Blast Radius
The affected code lives in ext4, still one of the default answers to the question, “What filesystem is this Linux system actually using?” It appears across distributions, cloud images, appliances, Android-derived systems, embedded devices, rescue environments, and many self-managed servers. Even Windows-heavy shops often encounter it through Linux virtual machines, WSL workflows, container hosts, backup targets, hypervisors, and storage appliances.CVE-2026-45899 is currently marked as awaiting NVD enrichment, with no NIST CVSS score assigned as of publication. That matters because severity dashboards often treat “no score yet” as a kind of limbo. In practice, administrators should read this as not yet classified, not as not important.
The vulnerability description says the problem occurs when splitting an ext4 extent fails. Some extents may still be in the middle of processing, and a direct error return can leave stale extent entries in the extent status tree. The upstream remedy is to drop the remaining potentially stale extents when the split fails.
That is a terse kernel explanation, but it points to a familiar class of storage bugs: the authoritative on-disk metadata and the in-memory acceleration structures can drift apart under an error path. The filesystem may not be “corrupt” in the dramatic, unmountable sense. It may simply be making decisions with stale information, which is often how the worst debugging sessions begin.
Extents Are the Map, and This Bug Is About a Bad Copy of the Map
Ext4 uses extents to describe ranges of file data more efficiently than old block-by-block mapping. Instead of recording every individual block for a large contiguous file, the filesystem can say, in effect, “this logical range of the file lives over there on disk.” That model is one reason ext4 has aged so well across workloads that range from tiny boot partitions to large application data volumes.But extents are not static. Files are appended, truncated, preallocated, punched full of holes, rewritten, journaled, and moved through error conditions that storage engineers would rather not see at 3 a.m. Splitting an extent is one of those ordinary but delicate operations: a previously continuous range must be divided so the filesystem can represent a changed portion accurately.
The extent status tree is an in-memory structure used to cache extent state. Like most caches, it exists to avoid expensive repeated work. Like all caches, it becomes dangerous when it preserves information that the rest of the system can no longer trust.
CVE-2026-45899 sits precisely at that seam. If an extent split fails, the cleanup must be just as careful as the successful path. The kernel patch says the previous logic could leave entries behind that were still being processed. That is the kind of bug that rarely produces a simple user-facing symptom, because the user-visible failure may happen later, somewhere else, under a workload that merely happens to step on the stale state.
The Security Label Is Doing More Work Than the Scoreboard
Kernel CVEs often frustrate security teams because they do not map cleanly to the mental model built around browser bugs, exposed web services, or privilege-escalation exploits. A filesystem consistency defect can be security-relevant without being easily weaponized across the network. It can be serious in one environment and nearly irrelevant in another.That is especially true while NVD has not yet assigned a CVSS vector. A final score may eventually classify the issue as modest, or it may flag availability and integrity impacts more clearly. Until then, the prudent reading is operational: this is a kernel bug in a default-class filesystem, fixed upstream and backported across stable branches.
The absence of a score should not be confused with the absence of risk. CVSS is useful for triage, but storage-layer defects often cut across the categories that scoring systems flatten. If stale extent state can lead to incorrect behavior, the most immediate concern is usually data integrity or system stability, not an attacker popping a shell.
That does not make it uninteresting to security teams. Availability is a security property. So is integrity. A bug that can help produce a filesystem error, stale mapping, unexpected kernel warning, or data-handling anomaly belongs in the patch queue even if nobody has shown a polished exploit.
The Real Risk Is Not Panic, but Patch Amnesia
For many organizations, the most dangerous kernel bug is not the one with the highest score. It is the one that falls between teams. Security waits for a CVSS number. Infrastructure waits for the distro advisory. Application owners assume the platform team has it. The platform team assumes the appliance vendor will absorb it. Six months later, the vulnerable code is still running in a forgotten VM template.CVE-2026-45899 is a good test of that failure mode. It is not likely to dominate general technology news. It does not have the obvious urgency of an internet-facing remote exploit. Yet it affects a component that many systems depend on precisely because nobody wants to think about it.
The kernel.org references show fixes across multiple stable commits, which usually means the change has been carried into several maintained kernel lines rather than left only in the development tree. That is encouraging, but it also pushes the burden downstream. Most administrators do not run kernels directly from kernel.org; they run Ubuntu, Debian, Fedora, Red Hat Enterprise Linux, SUSE, Arch, Proxmox, TrueNAS-derived components, Android kernels, cloud-tuned kernels, or vendor-maintained appliance builds.
That distribution layer matters. A server can be “up to date” according to one package repository and still be waiting for a vendor’s kernel rebuild. A container can be patched in user space while the host kernel remains unchanged. A Windows laptop running WSL can have fully current Linux packages inside the distro while the relevant kernel behavior depends on Microsoft’s WSL kernel servicing path.
Windows Shops Are Not Spectators Anymore
It is tempting for Windows administrators to file this under “Linux problem” and move on. That instinct is increasingly outdated. Mixed estates are the norm, and Linux filesystems frequently appear in places where the business still thinks of itself as a Windows shop.WSL is the obvious bridge. Developers using WSL may store project trees on Linux-backed filesystems and run build pipelines that stress metadata paths in ways ordinary desktop usage does not. The more important exposure, however, is usually server-side: Linux VMs in Hyper-V, Kubernetes nodes, CI runners, backup repositories, monitoring appliances, and cloud workloads that authenticate against Microsoft identity but boot a Linux kernel.
Ext4 also shows up in recovery and migration workflows. Administrators may mount Linux volumes from rescue images, clone disks between environments, or run forensic tooling against ext4 partitions. If the kernel doing that work has a filesystem bug, the fact that the surrounding estate is Windows-centric offers little comfort.
For WindowsForum.com readers, the practical point is not that every Windows admin must become an ext4 maintainer. It is that the boundary between Microsoft infrastructure and Linux plumbing has blurred. Active Directory, Entra ID, Hyper-V, Windows Server, Azure, WSL, and Linux guests often coexist in the same operational chain. A storage-layer bug in one link can become an outage in a place whose dashboard says “Windows.”
Error Paths Are Where Mature Filesystems Show Their Age
Ext4’s reputation is built on boring reliability, and boring reliability is a compliment. It is the filesystem people choose when they want fewer surprises, not more. But mature codebases carry a particular kind of complexity: years of fixes, optimizations, fast paths, journaling interactions, delayed allocation behavior, and compatibility promises all layered atop one another.The interesting part of CVE-2026-45899 is that it lives in an error path. The normal path is often hammered by everyday testing. The failure path is where timing, allocation pressure, unusual workloads, and partial state combine. That is where caches are hardest to reason about.
A failed extent split is not supposed to be the common case. But robust filesystems are judged by what they do when the uncommon case happens. Returning an error is not enough if the function has already changed in-memory state. Cleanup must restore invariants, not just stop the current operation.
That is the engineering story behind the phrase “drop extent cache.” It is not a performance tweak masquerading as a vulnerability fix. It is a correctness fix: if the cache may now be stale, throw away the suspect knowledge and force the system to rebuild from safer ground.
Stale Metadata Is the Kind of Bug That Makes Logs Look Innocent
One reason filesystem defects are so difficult for administrators is that symptoms often arrive without an obvious cause. A database reports I/O errors. A VM image behaves strangely. A backup job fails validation. A kernel log shows ext4 complaints hours after the workload that triggered the bad state. The human on call sees the smoke, not the spark.Stale extent status entries are especially awkward because they are not the same thing as a blatantly damaged disk. Hardware diagnostics may pass. SMART counters may look fine. The storage array may insist everything is healthy. The application may retry and recover, leaving only a suspicious line in the logs.
This is why kernel patching cannot be reduced to exploit-chasing. The bugs that cost the most operational time are often the ones that create ambiguity. Is it the SSD? The hypervisor? The guest kernel? The filesystem? The database? The backup tool? The answer may be a narrow ext4 error path that only shows up when a write pattern meets a failure condition.
In that sense, CVE-2026-45899 is less a standalone drama than a reminder of how many systems depend on silent correctness. When the filesystem cache is right, nobody notices. When it is wrong, every layer above it becomes a suspect.
Backports Are the Good News, but They Are Not Deployment
The upstream fix appears in several stable kernel references, which is the Linux maintenance model working as intended. A bug is found, a small targeted patch is accepted, and stable maintainers propagate it into supported lines. That process is one of the reasons Linux can be both fast-moving and dependable.But backported is not the same as deployed. Enterprise Linux users live behind vendor kernels. Cloud users live behind image pipelines and managed node pools. Appliance users live behind firmware bundles. Developers live behind whatever kernel their laptop, WSL installation, or distro channel happens to ship.
Administrators should therefore resist the easy question, “Is this fixed in Linux?” The better question is, “Is this fixed in the kernel I am actually booting?” That means checking distribution advisories, package changelogs, kernel build numbers, and vendor notices rather than relying on the existence of an upstream commit.
This distinction matters even more for long-term-support kernels. Stable trees receive many fixes, but organizations often pin kernels for hardware certification, driver compatibility, or change-control reasons. A storage fix can sit available for weeks while production remains deliberately frozen.
The Patch Should Be Boring; the Rollout Should Be Disciplined
The appropriate response is not emergency theater. There is no public evidence in the provided record of active exploitation, and the NVD entry does not yet provide a severity score. Treating every kernel CVE as a four-alarm fire is how teams burn out and eventually ignore the alarms that matter.The right response is disciplined patch management. Identify systems using ext4. Determine which kernel versions and vendor builds contain the fix. Prioritize machines with heavy write workloads, virtualization hosts, CI infrastructure, storage-heavy services, and systems where filesystem inconsistency would be expensive to diagnose.
For production Linux servers, this will usually mean scheduling a kernel update and reboot through normal maintenance channels. For cloud and Kubernetes environments, it may mean rotating nodes rather than patching them in place. For WSL, it means watching Microsoft’s servicing of the WSL kernel rather than assuming the Linux userland distribution controls everything.
Backups deserve a special mention. Filesystem bugs are exactly why backups should be verified, not merely created. If a system has shown ext4 errors, odd I/O behavior, or unexplained data inconsistency, administrators should not treat patching as retroactive repair. Apply the fix, then validate the data and the recovery path.
The NVD Delay Shows the Limits of Score-First Security
NVD enrichment lag is not new, and kernel CVEs make the issue particularly visible. The record can exist with an accurate upstream description, references, publication date, and change history while the fields many dashboards depend on remain empty. That creates an uncomfortable gap between disclosure and automated prioritization.Security tooling is only as useful as the metadata it consumes. If a vulnerability has no CVSS score, some systems under-rank it. If the affected product mapping is incomplete, asset scanners may miss it. If the description is technically dense, risk owners may not understand whether the issue matters in their environment.
This is where human judgment still earns its keep. A CVE in ext4 is not just a line item. It intersects with storage architecture, workload behavior, kernel maintenance, and recovery planning. A low-level bug with a limited trigger can still deserve prompt attention on systems that cannot tolerate filesystem weirdness.
The industry likes to pretend vulnerability management is a spreadsheet exercise. CVE-2026-45899 argues otherwise. The spreadsheet can tell you the record exists. It cannot tell you which of your aging Linux VMs hosts the one workload that will make a stale extent cache ruin your week.
The Kernel CVE Factory Is Also a Transparency Machine
There is a broader story here about the Linux kernel’s CVE process. In recent years, kernel.org has pushed a large number of vulnerability records for bugs fixed in the kernel, including issues that look to outsiders more like correctness fixes than traditional security flaws. Critics see noise. Maintainers see a more consistent way to tell users that fixed bugs in privileged code can have security consequences.Both views have merit. The flood of kernel CVEs can make prioritization harder, especially when many arrive without immediate severity scores. But the alternative is not a clean, perfectly curated universe. The alternative is a world where low-level fixes disappear into commit logs and only become “security” issues when someone later demonstrates a practical attack or outage.
For administrators, the answer is not to dismiss kernel CVEs wholesale. It is to build better filters. Filesystem, memory-management, networking, and privilege-boundary bugs should not be treated identically. A local-only bug on a single-purpose kiosk is not the same as a filesystem bug on a multi-tenant storage host.
CVE-2026-45899 is a useful example because it does not need to be sensational to be worth tracking. It is the kind of defect that rewards teams with good asset knowledge and punishes teams that manage kernels as an afterthought.
The Practical Test Is Whether You Know Where ext4 Still Lives
The first operational question is simple: where are you using ext4? The answer is often less obvious than expected. Root disks, data volumes, old VM templates, development machines, backup appliances, lab systems, and one-off cloud instances may all be in scope.The second question is whether those systems receive kernel updates through a channel you control and monitor. A fleet managed by a modern configuration platform is one thing. A collection of vendor appliances, forgotten pet servers, and hand-built VMs is another.
The third question is what would happen if ext4 behaved incorrectly on those systems. A developer workstation may be inconvenient. A database host may be business-critical. A backup repository may be existentially important during an incident. Risk is not just vulnerability times exploitability; it is vulnerability times where the vulnerable thing sits.
This is where security and operations need to meet. Security teams can flag the CVE. Operations teams can identify the actual kernels and filesystems. Application owners can explain the cost of downtime or data inconsistency. Without all three, the organization is guessing.
CVE-2026-45899 Rewards the Teams That Patch Before the Story Gets Loud
The concrete action is straightforward: track the kernel fix through your distribution or vendor, then deploy it according to the importance of the systems involved. The more subtle action is to treat this as a prompt to improve kernel visibility. A team that cannot answer which ext4 systems are running which kernels has a bigger problem than this one CVE.- Systems using ext4 should be inventoried across servers, virtual machines, appliances, developer environments, and WSL-adjacent workflows.
- Administrators should verify the fix in the kernel package or vendor build they actually deploy, not merely in the upstream stable tree.
- Storage-heavy and write-heavy systems deserve earlier attention because extent-splitting paths are more relevant under active filesystem mutation.
- A patched kernel does not prove existing data is healthy, so systems with prior ext4 errors or unexplained I/O anomalies should receive additional validation.
- Organizations should avoid waiting for NVD scoring before triaging filesystem bugs that affect integrity or availability-sensitive workloads.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:02:59-07:00
NVD - CVE-2026-45899
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:02:59-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: kernel.googlesource.com
- Related coverage: opennet.ru
- Related coverage: git.zx2c4.com
linux-rng - Development tree for the kernel CSPRNG
git.zx2c4.com
- Related coverage: lists.linaro.org
- Related coverage: android.googlesource.com
- Related coverage: kernel.org
