CVE-2026-46159, published by NVD on May 28, 2026 and sourced from kernel.org, is a Linux kernel Btrfs vulnerability in
At first glance, CVE-2026-46159 sounds like the kind of kernel CVE that disappears into distribution changelogs. It lives in Btrfs, it concerns an ioctl, and the affected code reports space information rather than handling credentials, networking, or cryptography. That combination tempts defenders to file it under “patch when convenient.”
That would be the wrong instinct. The vulnerability is a kernel information leak, and kernel information leaks matter because they erode one of the basic assumptions behind modern exploit mitigation: that attackers should not be able to casually learn what is sitting in kernel memory. Even when an info leak does not hand over a password, a key, or a complete exploit chain, it can reduce uncertainty for an attacker who is trying to defeat address randomization, inspect heap state, or chain bugs together.
The awkward part is that the vulnerable behavior emerges from mundane bookkeeping. Btrfs has to report filesystem space information to userspace. To do that, the kernel code counts how many entries it expects, allocates a buffer large enough to hold them, fills that buffer, and copies the result back. The problem is that the world can change between counting and copying.
That is the classic time-of-check to time-of-use pattern, or TOCTOU, dressed in filesystem clothing. The first pass decides how much memory is needed. The second pass discovers what is actually still there. If those two realities diverge, the kernel may copy more than it actually initialized.
That lock release is the hinge of the bug. Once the lock is dropped, concurrent filesystem activity can remove block groups and reduce the number of entries that the second pass will actually fill. The allocation still reflects the earlier, larger count, but the initialized content reflects the later, smaller state.
The consequence is subtle but serious. If the function copies the full originally allocated size back to userspace, the tail of the buffer can contain uninitialized bytes from a kernel allocation. In other words, userspace requested space information and may receive leftover heap contents that were never meant to cross the kernel boundary.
This is not a dramatic buffer overflow. Nothing in the description says an attacker overwrites control flow or gains privileges directly. But the boundary violation is real:
That does not mean CVE-2026-46159 should be treated as an internet-scale emergency. Based on the public description, this is a local kernel issue in Btrfs code, and exploitation appears to depend on being able to exercise the relevant ioctl and race it against block group changes. Those conditions are narrower than a remotely reachable network daemon.
The risk calculus changes in multi-user systems, developer workstations, lab servers, and container-heavy environments where local attack paths matter. A Linux desktop running Btrfs for a single trusted user is not the same as a shared build host where untrusted jobs can run code. A NAS appliance using Btrfs is not the same as a cloud VM image where tenant isolation is the whole business model.
The important point is not panic. It is classification. This is a confidentiality flaw in kernel space, and administrators should treat it as part of the steady pressure to keep kernels current, especially on systems where local users or workloads are not fully trusted.
The patch also switches allocation to
This two-part fix is a useful reminder that safe kernel code often requires defensive redundancy. The primary repair is logical: copy only what was filled. The secondary mitigation is hygienic: ensure that slack space is zeroed so future mistakes degrade safely.
There is a performance cost to zeroing memory, but in this context the tradeoff is easy to defend. The affected path is not the hottest inner loop of packet processing or scheduler code. It is an ioctl reporting filesystem space state. When the alternative is leaking heap residue to userspace, zeroing is not overengineering; it is prudence.
CVE-2026-46159 does not imply that Btrfs is uniquely careless. Kernel filesystems are complex, concurrent, stateful systems, and they sit at the intersection of storage, memory management, locking, and userspace interfaces. Bugs appear in ext4, XFS, overlayfs, network filesystems, and virtual filesystems too.
Still, Btrfs’ feature set creates many places where state can change while the kernel is preparing an answer for userspace. Space accounting is not a static spreadsheet; block groups can come and go, allocation profiles can shift, and maintenance operations can reshape the filesystem underneath the reporting code. That dynamism is exactly where TOCTOU bugs breed.
For WindowsForum readers, the Linux angle matters even if Windows remains the daily driver. Btrfs shows up in dual-boot systems, WSL-adjacent development workflows, home labs, NAS distributions, backup targets, and Linux servers that Windows administrators increasingly manage alongside Active Directory, Azure, and Microsoft 365. The filesystem may be “not Windows,” but the operational blast radius often lands on the same IT desk.
Kernel.org-sourced CVEs often arrive with terse descriptions and patch references before downstream vendors have published their own advisories. Distribution trackers, enterprise vendors, and cloud providers then decide which supported kernels are affected, which backports are required, and how to communicate severity to customers. That process takes time.
Administrators should be careful not to let NVD’s enrichment lag become a patching delay. The actionable facts are already present: a Linux kernel Btrfs function can leak uninitialized kernel heap bytes to userspace under a race condition, and stable kernel commits exist to fix it. That is enough to start inventory and exposure review.
The more interesting issue is that modern vulnerability management still depends too heavily on numeric severity as a first filter. A CVSS score is useful, but it is not a substitute for context. A medium-scored kernel information leak on a shared host may deserve faster action than a higher-scored bug in a component that is not installed anywhere in the environment.
The race depends on timing and state changes. An attacker would need to trigger the relevant space-info ioctl while concurrent block group removal changes the number of entries between passes. Filesystem races are often finicky, but finicky is not the same as impossible, especially when the attacker can run repeated attempts on a local machine.
The public description does not claim privilege escalation, remote access, or arbitrary memory disclosure. It says trailing uninitialized heap bytes may be copied to userspace. That distinction matters, because defenders should avoid inflating every kernel CVE into a catastrophe.
But minimizing it would be equally wrong. Kernel heap disclosure can expose material whose significance is not obvious until paired with another bug. Attackers do not need every primitive to be spectacular; they need a sequence of primitives that fit together.
Some organizations standardize on XFS or ext4 and rarely touch Btrfs in production. Others use it heavily, especially in backup appliances, SUSE-derived environments, homegrown storage systems, or developer workstations. In some cases, Btrfs support may be built as a module even if the root filesystem is something else.
The exposure model also depends on local access. A single-purpose server with no shell users and tightly controlled workloads presents a different risk than a CI runner executing arbitrary project code. Workstations used by developers, security researchers, or contractors can also matter because local code execution is assumed in many attack scenarios.
The right patching posture is boring but effective: track vendor kernel updates, deploy them through normal maintenance channels, and reboot into the fixed kernel. Kernel patches do not help until the running kernel changes, and that reboot requirement remains one of the oldest frictions in Linux fleet management.
The most obvious crossover is virtualization. Hyper-V hosts may run Linux guests. Windows admins may be responsible for patch windows, backup validation, and vulnerability reports even when the guest OS is managed by another team. If those guests use Btrfs, the remediation path needs coordination.
There is also the WSL-adjacent reality. WSL itself does not make every Linux kernel filesystem feature relevant in the same way as a native Linux install, and administrators should not assume this CVE directly maps onto every WSL deployment. But the broader pattern is familiar: Windows users are running more Linux tooling, and the line between “desktop feature” and “server-grade kernel behavior” keeps blurring.
For mixed estates, the lesson is organizational. Vulnerability management cannot stop at product boundaries. If Windows admins own the asset, the patch window, or the compliance report, they need enough Linux literacy to recognize when a filesystem CVE is noise and when it is a real local-risk item.
CVE-2026-46159 is a failure of that discipline, not because the code recklessly copied a random pointer, but because it copied a buffer size derived from stale state. That is the unnerving part. The code structure is plausible. Count, allocate, fill, copy. Many C programmers have written that pattern.
Concurrency makes the pattern dangerous. In a single-threaded world, the count would remain true long enough to use. In the kernel, state changes constantly, locks shape reality, and dropping a lock between two related observations means the second observation may not match the first.
This is why kernel fixes often look small compared with the risk they close. A copy length changes. An allocator call gains a zeroing guarantee. A lock is held differently. The patch may be a handful of lines, but the security property it restores is fundamental.
That rule applies far beyond Btrfs. Network stacks, device drivers, procfs handlers, sysfs attributes, and ioctl-heavy subsystems all face variants of the same problem. Any code that reports a variable-length kernel data structure to userspace has to answer the same question: what happens if the data changes while we are building the response?
The switch to
Security engineering often advances through exactly these small hardening moves. They are not glamorous. They do not produce a new feature. But they convert classes of mistakes from exploitable failures into harmless inefficiencies.
Rolling distributions may pick up the fix quickly as part of routine kernel updates. Enterprise distributions may backport the patch into older supported kernels without changing the visible upstream version number. Appliances may lag unless the vendor has a mature kernel update process.
This creates a familiar vulnerability-management trap. A scanner may flag the CVE based on version heuristics, while the vendor may have already backported the fix. Or the reverse may happen: a kernel version appears “new enough” in broad terms but lacks the specific stable patch. Administrators should rely on vendor advisories and package changelogs, not just upstream version comparisons.
For regulated environments, documentation matters. If a Linux fleet uses Btrfs anywhere, teams should record whether the running vendor kernel includes the fix, when it was deployed, and when systems rebooted into it. The vulnerability is technical; the audit trail is operational.
An attacker who lands as a low-privileged user, compromises a build account, escapes a poorly isolated workload, or abuses a developer machine will look for local ways to expand access or gather information. A kernel info leak may help map memory, defeat mitigations, or prepare a second-stage exploit. It may also reveal data that is valuable in its own right, depending on what heap contents are exposed.
None of that proves CVE-2026-46159 is a practical exploit component today. It does explain why defenders should not dismiss it because it lacks a dramatic score or because the word “Btrfs” sounds niche. The kernel attack surface is broad, and local primitives accumulate.
The sensible posture is proportional urgency. Patch promptly in normal kernel update cycles, accelerate for shared or untrusted local-execution environments, and do not burn emergency weekend hours unless vendor guidance or exploit evidence changes the picture.
btrfs_ioctl_space_info() where a race condition can cause uninitialized kernel heap memory to be copied to userspace. The bug is not a remote-code-execution headline-grabber, and NVD had not yet assigned a CVSS score when the record appeared. But it is exactly the sort of flaw that should make administrators uneasy: small, local, filesystem-specific, and rooted in a boundary where the kernel promises userspace only the information it intentionally exposes. The fix is simple; the lesson is larger.
A Filesystem Accounting Bug Becomes a Kernel Confidentiality Problem
At first glance, CVE-2026-46159 sounds like the kind of kernel CVE that disappears into distribution changelogs. It lives in Btrfs, it concerns an ioctl, and the affected code reports space information rather than handling credentials, networking, or cryptography. That combination tempts defenders to file it under “patch when convenient.”That would be the wrong instinct. The vulnerability is a kernel information leak, and kernel information leaks matter because they erode one of the basic assumptions behind modern exploit mitigation: that attackers should not be able to casually learn what is sitting in kernel memory. Even when an info leak does not hand over a password, a key, or a complete exploit chain, it can reduce uncertainty for an attacker who is trying to defeat address randomization, inspect heap state, or chain bugs together.
The awkward part is that the vulnerable behavior emerges from mundane bookkeeping. Btrfs has to report filesystem space information to userspace. To do that, the kernel code counts how many entries it expects, allocates a buffer large enough to hold them, fills that buffer, and copies the result back. The problem is that the world can change between counting and copying.
That is the classic time-of-check to time-of-use pattern, or TOCTOU, dressed in filesystem clothing. The first pass decides how much memory is needed. The second pass discovers what is actually still there. If those two realities diverge, the kernel may copy more than it actually initialized.
The Dangerous Gap Between “How Much” and “What Exists”
The NVD description says the vulnerable function performs two passes over Btrfs block group RAID type lists. During the first pass, the function counts entries to determine an allocation size. Between that first count and the second pass, the relevant read-write lock is released.That lock release is the hinge of the bug. Once the lock is dropped, concurrent filesystem activity can remove block groups and reduce the number of entries that the second pass will actually fill. The allocation still reflects the earlier, larger count, but the initialized content reflects the later, smaller state.
The consequence is subtle but serious. If the function copies the full originally allocated size back to userspace, the tail of the buffer can contain uninitialized bytes from a kernel allocation. In other words, userspace requested space information and may receive leftover heap contents that were never meant to cross the kernel boundary.
This is not a dramatic buffer overflow. Nothing in the description says an attacker overwrites control flow or gains privileges directly. But the boundary violation is real:
copy_to_user() is supposed to transfer deliberately prepared data, not whatever happened to be in the unused portion of a kmalloc allocation.Why “Just an Info Leak” Is Not Reassuring
Security teams have learned to distrust the phrase “just an info leak.” In kernel exploitation, disclosure bugs often play the role of accomplice rather than star witness. They may reveal pointers, object layouts, stale data, allocator behavior, or other fragments that turn a difficult exploit into a practical one.That does not mean CVE-2026-46159 should be treated as an internet-scale emergency. Based on the public description, this is a local kernel issue in Btrfs code, and exploitation appears to depend on being able to exercise the relevant ioctl and race it against block group changes. Those conditions are narrower than a remotely reachable network daemon.
The risk calculus changes in multi-user systems, developer workstations, lab servers, and container-heavy environments where local attack paths matter. A Linux desktop running Btrfs for a single trusted user is not the same as a shared build host where untrusted jobs can run code. A NAS appliance using Btrfs is not the same as a cloud VM image where tenant isolation is the whole business model.
The important point is not panic. It is classification. This is a confidentiality flaw in kernel space, and administrators should treat it as part of the steady pressure to keep kernels current, especially on systems where local users or workloads are not fully trusted.
The Fix Tells the Whole Story
The fix described in the CVE is refreshingly direct. Instead of copying the original allocation size back to userspace, the kernel should copy only the number of entries actually filled during the second pass. That means the copy length follows reality, not an earlier estimate.The patch also switches allocation to
kzalloc, which zeroes memory before use. That is a belt-and-suspenders move. If a future mismatch occurs, zero-filled memory is far less likely to disclose sensitive kernel heap contents than an ordinary uninitialized allocation.This two-part fix is a useful reminder that safe kernel code often requires defensive redundancy. The primary repair is logical: copy only what was filled. The secondary mitigation is hygienic: ensure that slack space is zeroed so future mistakes degrade safely.
There is a performance cost to zeroing memory, but in this context the tradeoff is easy to defend. The affected path is not the hottest inner loop of packet processing or scheduler code. It is an ioctl reporting filesystem space state. When the alternative is leaking heap residue to userspace, zeroing is not overengineering; it is prudence.
Btrfs Keeps Paying for Its Ambition
Btrfs is powerful because it tries to do many things inside the filesystem layer: snapshots, checksums, subvolumes, send and receive, compression, online maintenance, and flexible storage layouts. That ambition is why enthusiasts like it and why administrators choose it for certain workloads. It is also why the code surface is large.CVE-2026-46159 does not imply that Btrfs is uniquely careless. Kernel filesystems are complex, concurrent, stateful systems, and they sit at the intersection of storage, memory management, locking, and userspace interfaces. Bugs appear in ext4, XFS, overlayfs, network filesystems, and virtual filesystems too.
Still, Btrfs’ feature set creates many places where state can change while the kernel is preparing an answer for userspace. Space accounting is not a static spreadsheet; block groups can come and go, allocation profiles can shift, and maintenance operations can reshape the filesystem underneath the reporting code. That dynamism is exactly where TOCTOU bugs breed.
For WindowsForum readers, the Linux angle matters even if Windows remains the daily driver. Btrfs shows up in dual-boot systems, WSL-adjacent development workflows, home labs, NAS distributions, backup targets, and Linux servers that Windows administrators increasingly manage alongside Active Directory, Azure, and Microsoft 365. The filesystem may be “not Windows,” but the operational blast radius often lands on the same IT desk.
NVD’s Empty Score Is a Warning, Not an All-Clear
When the CVE record appeared, NVD had marked it as awaiting enrichment and had not yet provided CVSS 4.0, CVSS 3.x, or CVSS 2.0 scoring. That absence is easy to misread. No score does not mean no severity; it means the public vulnerability database has not completed that part of its workflow.Kernel.org-sourced CVEs often arrive with terse descriptions and patch references before downstream vendors have published their own advisories. Distribution trackers, enterprise vendors, and cloud providers then decide which supported kernels are affected, which backports are required, and how to communicate severity to customers. That process takes time.
Administrators should be careful not to let NVD’s enrichment lag become a patching delay. The actionable facts are already present: a Linux kernel Btrfs function can leak uninitialized kernel heap bytes to userspace under a race condition, and stable kernel commits exist to fix it. That is enough to start inventory and exposure review.
The more interesting issue is that modern vulnerability management still depends too heavily on numeric severity as a first filter. A CVSS score is useful, but it is not a substitute for context. A medium-scored kernel information leak on a shared host may deserve faster action than a higher-scored bug in a component that is not installed anywhere in the environment.
The Exploitability Question Is Narrower Than the Security Question
There is a difference between “can this be exploited in a reliable weaponized chain today?” and “does this violate a security boundary?” CVE-2026-46159 clearly belongs in the second category. The first category is harder to assess from the public record alone.The race depends on timing and state changes. An attacker would need to trigger the relevant space-info ioctl while concurrent block group removal changes the number of entries between passes. Filesystem races are often finicky, but finicky is not the same as impossible, especially when the attacker can run repeated attempts on a local machine.
The public description does not claim privilege escalation, remote access, or arbitrary memory disclosure. It says trailing uninitialized heap bytes may be copied to userspace. That distinction matters, because defenders should avoid inflating every kernel CVE into a catastrophe.
But minimizing it would be equally wrong. Kernel heap disclosure can expose material whose significance is not obvious until paired with another bug. Attackers do not need every primitive to be spectacular; they need a sequence of primitives that fit together.
Enterprise Linux Teams Should Look for Btrfs, Not Just Linux
The practical response starts with inventory. The question is not simply “Do we run Linux?” It is “Where do we run kernels with Btrfs enabled, mounted, or available to untrusted users?”Some organizations standardize on XFS or ext4 and rarely touch Btrfs in production. Others use it heavily, especially in backup appliances, SUSE-derived environments, homegrown storage systems, or developer workstations. In some cases, Btrfs support may be built as a module even if the root filesystem is something else.
The exposure model also depends on local access. A single-purpose server with no shell users and tightly controlled workloads presents a different risk than a CI runner executing arbitrary project code. Workstations used by developers, security researchers, or contractors can also matter because local code execution is assumed in many attack scenarios.
The right patching posture is boring but effective: track vendor kernel updates, deploy them through normal maintenance channels, and reboot into the fixed kernel. Kernel patches do not help until the running kernel changes, and that reboot requirement remains one of the oldest frictions in Linux fleet management.
Windows Administrators Still Have Skin in This Game
Windows shops increasingly run Linux whether they planned to or not. It appears in virtualization clusters, Kubernetes nodes, appliance VMs, security tools, build systems, developer laptops, and cloud workloads. A vulnerability in a Linux filesystem can therefore become a Windows administrator’s problem through the back door of infrastructure sprawl.The most obvious crossover is virtualization. Hyper-V hosts may run Linux guests. Windows admins may be responsible for patch windows, backup validation, and vulnerability reports even when the guest OS is managed by another team. If those guests use Btrfs, the remediation path needs coordination.
There is also the WSL-adjacent reality. WSL itself does not make every Linux kernel filesystem feature relevant in the same way as a native Linux install, and administrators should not assume this CVE directly maps onto every WSL deployment. But the broader pattern is familiar: Windows users are running more Linux tooling, and the line between “desktop feature” and “server-grade kernel behavior” keeps blurring.
For mixed estates, the lesson is organizational. Vulnerability management cannot stop at product boundaries. If Windows admins own the asset, the patch window, or the compliance report, they need enough Linux literacy to recognize when a filesystem CVE is noise and when it is a real local-risk item.
The Kernel’s User Copy Boundary Remains Sacred
The phrasecopy_to_user() deserves attention because it marks one of the kernel’s most important trust boundaries. Kernel memory is privileged. Userspace memory is not. Every copy from kernel to userspace must be intentional, bounded, and initialized.CVE-2026-46159 is a failure of that discipline, not because the code recklessly copied a random pointer, but because it copied a buffer size derived from stale state. That is the unnerving part. The code structure is plausible. Count, allocate, fill, copy. Many C programmers have written that pattern.
Concurrency makes the pattern dangerous. In a single-threaded world, the count would remain true long enough to use. In the kernel, state changes constantly, locks shape reality, and dropping a lock between two related observations means the second observation may not match the first.
This is why kernel fixes often look small compared with the risk they close. A copy length changes. An allocator call gains a zeroing guarantee. A lock is held differently. The patch may be a handful of lines, but the security property it restores is fundamental.
The Patch Is Also a Coding Standard in Disguise
The most useful way to read this fix is as a coding rule: never let an earlier count define a later user-visible copy if the object set can change in between. Either hold the necessary lock across the whole operation, revalidate the count, or make the copy length depend on what was actually produced.That rule applies far beyond Btrfs. Network stacks, device drivers, procfs handlers, sysfs attributes, and ioctl-heavy subsystems all face variants of the same problem. Any code that reports a variable-length kernel data structure to userspace has to answer the same question: what happens if the data changes while we are building the response?
The switch to
kzalloc adds a second rule: when data might cross privilege boundaries, zeroing unused memory is cheap insurance. Zeroing should not be used to paper over broken length accounting, but it can prevent a future length bug from becoming a disclosure bug.Security engineering often advances through exactly these small hardening moves. They are not glamorous. They do not produce a new feature. But they convert classes of mistakes from exploitable failures into harmless inefficiencies.
Vendors Will Decide How Fast This Reaches Real Machines
Upstream stable commits are only the beginning. Most administrators do not run kernels directly from kernel.org; they run distribution kernels with patches backported into vendor-maintained branches. That means the practical fix arrives through Red Hat, Canonical, SUSE, Debian, Arch, Fedora, appliance vendors, cloud images, and embedded maintainers on their own schedules.Rolling distributions may pick up the fix quickly as part of routine kernel updates. Enterprise distributions may backport the patch into older supported kernels without changing the visible upstream version number. Appliances may lag unless the vendor has a mature kernel update process.
This creates a familiar vulnerability-management trap. A scanner may flag the CVE based on version heuristics, while the vendor may have already backported the fix. Or the reverse may happen: a kernel version appears “new enough” in broad terms but lacks the specific stable patch. Administrators should rely on vendor advisories and package changelogs, not just upstream version comparisons.
For regulated environments, documentation matters. If a Linux fleet uses Btrfs anywhere, teams should record whether the running vendor kernel includes the fix, when it was deployed, and when systems rebooted into it. The vulnerability is technical; the audit trail is operational.
The Real Risk Is Complacency Around Local Bugs
Local kernel bugs occupy an awkward place in enterprise prioritization. They are less urgent than remote unauthenticated flaws, but they are often more useful to attackers who already have a foothold. Modern intrusions are rarely single-step events. They are chains.An attacker who lands as a low-privileged user, compromises a build account, escapes a poorly isolated workload, or abuses a developer machine will look for local ways to expand access or gather information. A kernel info leak may help map memory, defeat mitigations, or prepare a second-stage exploit. It may also reveal data that is valuable in its own right, depending on what heap contents are exposed.
None of that proves CVE-2026-46159 is a practical exploit component today. It does explain why defenders should not dismiss it because it lacks a dramatic score or because the word “Btrfs” sounds niche. The kernel attack surface is broad, and local primitives accumulate.
The sensible posture is proportional urgency. Patch promptly in normal kernel update cycles, accelerate for shared or untrusted local-execution environments, and do not burn emergency weekend hours unless vendor guidance or exploit evidence changes the picture.
The Btrfs Race Leaves Administrators With a Short, Concrete Checklist
CVE-2026-46159 is a compact vulnerability with a compact operational response. The bug is in a specific Btrfs ioctl path, the impact is kernel heap information disclosure to userspace, and the fix is already described in upstream stable commits. The remaining work is making sure the fix reaches the machines where Btrfs and local code execution intersect.- Administrators should identify systems that use Btrfs or expose Btrfs functionality to users, containers, build jobs, or appliance workloads.
- Security teams should treat the absence of an NVD score as incomplete enrichment, not as evidence that the vulnerability is harmless.
- Kernel updates should be validated against vendor advisories or changelogs because enterprise kernels often receive backported fixes without obvious version jumps.
- Shared Linux hosts, CI runners, developer workstations, and storage appliances deserve higher priority than single-user machines with tightly controlled workloads.
- Reboots or live-patching confirmation should be part of remediation tracking because installing a fixed kernel package does not necessarily change the running kernel.
- Mixed Windows and Linux environments should route this through normal infrastructure ownership rather than assuming a Linux filesystem bug has no Windows operational impact.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:04:26-07:00
NVD - CVE-2026-46159
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:04:26-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cve.imfht.com
CVE-2026-31434: btrfs: fix leak of kobject name for sub-group space_info
## Overview In the Linux kernel Btrfs file system, when creating elements of `space_info->sub_group[]`, `kobject_init_and_add()` is called, but the corresponding cleanup function is not invoked duri
cve.imfht.com
- Related coverage: security.snyk.io
Snyk Vulnerability Database | Snyk
Medium severity (4.7) Time-of-check Time-of-use (TOCTOU) in kernel-headers | CVE-2026-23181
security.snyk.io
- Related coverage: support.bull.com
