| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Windows Win32k Elevation of Privilege Vulnerability |
| Windows Overlay Filter Elevation of Privilege Vulnerability |
| Windows User Profile Service Elevation of Privilege Vulnerability |
| Windows Event Tracing Elevation of Privilege Vulnerability |
| Windows WalletService Elevation of Privilege Vulnerability |
| Windows Projected File System Elevation of Privilege Vulnerability |
| Windows Graphics Component Elevation of Privilege Vulnerability |
| Windows Update Service Elevation of Privilege Vulnerability |
| Windows Container Execution Agent Elevation of Privilege Vulnerability |
| Windows Virtual Registry Provider Elevation of Privilege Vulnerability |
| Windows Win32k Elevation of Privilege Vulnerability |
| Windows Installer Elevation of Privilege Vulnerability |
| Windows Graphics Component Remote Code Execution Vulnerability |
| Windows App-V Overlay Filter Elevation of Privilege Vulnerability |
| Microsoft Power BI Information Disclosure Vulnerability |
| HEVC Video Extensions Remote Code Execution Vulnerability |
| Windows Error Reporting Elevation of Privilege Vulnerability |
| Windows Print Spooler Elevation of Privilege Vulnerability |
| HEVC Video Extensions Remote Code Execution Vulnerability |
| In the Linux kernel, the following vulnerability has been resolved:
fscrypt: Avoid dynamic allocation in fscrypt_get_devices()
When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls
fscrypt_get_devices() to get the filesystem's list of block devices,
then iterates over them and calls blk_crypto_config_supported(),
blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.
Currently, the block device pointers are placed in a dynamically
allocated array. This dynamic allocation is problematic because:
- It can fail, especially at the fscrypt_destroy_inline_crypt_key() call
site when it's invoked for inode eviction under direct reclaim.
- fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It
just zeroizes and frees the blk_crypto_key without calling
blk_crypto_evict_key(). That causes a use-after-free.
For now, let's fix this in the straightforward and easily-backportable
way by switching to an on-stack array. Currently the fscrypt
multi-device functionality is used only by f2fs, which has a hardcoded
limit of 8 block devices. An on-stack array works fine for that.
(Of course, this solution won't scale up to large number of block
devices. For that we'd need a different solution, like moving the block
device iteration into the filesystem. Or in the case of btrfs, which
will only support blk-crypto-fallback, we should make it just call
blk-crypto-fallback directly, so the block devices won't be needed.) |
