CVE-2026-46159
Received Received - Intake
Heap Info-Leak in Linux Kernel Btrfs

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's btrfs filesystem, specifically in the btrfs_ioctl_space_info() function. It involves a Time-Of-Check to Time-Of-Use (TOCTOU) race condition between two passes over block group RAID type lists. The first pass counts the number of entries to allocate memory, and the second pass fills a buffer with those entries. However, the lock protecting the data is released between these passes, allowing concurrent removal of block groups which can reduce the number of entries.

Because of this race, the second pass may fill fewer entries than the first pass counted. When data is copied to userspace, the function copies the originally allocated size, which includes uninitialized memory from the kernel heap. This can lead to leaking sensitive kernel memory contents to userspace.

The fix involves copying only the actual number of entries filled during the second pass and using zero-initialized memory allocation to prevent leaking uninitialized data.


How can this vulnerability impact me? :

This vulnerability can lead to an information leak where uninitialized kernel heap memory is exposed to userspace applications. An attacker with access to the vulnerable btrfs ioctl interface could potentially read sensitive kernel memory contents, which might include sensitive data or pointers that could aid further attacks.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart