Описание
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: Add missing superblock check in find_or_insert_direct_key()
The legacy 'fscrypt_direct_keys' table caches master keys that are used
by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.
It's just a global table for all filesystems (since the keys can be
provided by the legacy process-subscribed keyrings mechanism, which
makes it difficult to reuse super_block::s_master_keys).
The entries in it ('struct fscrypt_direct_key') do contain a super_block
pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when
the last inode that references the key is evicted.
However, when finding the fscrypt_direct_key for an inode, we weren't
actually comparing the super_block pointer. As a result, inodes with
different super_blocks could point to the same fscrypt_direct_key. That
could extend the lifetime of a fscrypt_direct_key beyond the
super_block it points to, causing a use-after-free later.
Fix this by creating distinct fscrypt_direct_key structs for distinct
super_block structs.
Note that this problem doesn't exist in the v2 policy equivalent
("per-mode keys"), since the data structures there are per super_block.
A flaw was found in the Linux kernel's fscrypt component. A missing superblock check in the find_or_insert_direct_key() function could allow inodes from different filesystems to incorrectly share encryption keys. This can lead to a use-after-free vulnerability, potentially allowing an attacker to cause a denial of service, disclose sensitive information, or execute arbitrary code.
Отчет
A moderate use-after-free vulnerability in the Linux kernel's fscrypt (filesystem encryption) subsystem affects Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10, and Red Hat In-Vehicle OS. The legacy global fscrypt_direct_keys table caches master keys used by v1 encryption policies that specify FSCRYPT_POLICY_FLAG_DIRECT_KEY. When find_or_insert_direct_key() looked up the direct key for an inode, it did not compare the super_block pointer, so inodes from different filesystems could reference the same fscrypt_direct_key structure. This could extend the lifetime of that structure beyond the lifetime of the superblock it points to, causing a use-after-free when the key is later destroyed. A local attacker able to use fscrypt with v1 direct-key policies on multiple filesystems could potentially exploit this flaw to cause a denial of service, disclose sensitive information, or execute arbitrary code; however, the specific conditions required make exploitation difficult, and Red Hat has assessed the attack complexity as high. Only filesystems that use legacy v1 encryption policies with the direct-key flag are exposed to this flaw; v2 encryption policies are not affected because their per-mode keys are maintained in per-superblock data structures. Red Hat Enterprise Linux 6, 7, and 8 are not affected because the vulnerable code is not present in their kernels. A fix for the affected products is being pursued by the Red Hat kernel team. Red Hat rates this flaw as Moderate severity, while the upstream CVE record assigns a CVSS 3.1 base score of 7.8 (Important); this difference reflects the high attack complexity and the limited set of configurations that use v1 direct-key encryption policies.
Меры по смягчению последствий
Systems can reduce exposure to this issue by avoiding legacy v1 fscrypt encryption policies that set the FSCRYPT_POLICY_FLAG_DIRECT_KEY flag: v2 encryption policies are not affected because their per-mode key structures are maintained per superblock. For existing deployments where switching to v2 encryption policies is not practical, mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Affected | ||
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel | Affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux for NVIDIA 26 | kernel | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Not affected |
Показывать по
Дополнительная информация
Статус:
7 High
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later....
In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later
fscrypt: Add missing superblock check in find_or_insert_direct_key()
In the Linux kernel, the following vulnerability has been resolved: f ...
In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free la...
7 High
CVSS3