CVE-2026-64192 in Linux
Сводка
по VulDB • 21.07.2026
В ядре Linux устранена следующая уязвимость:
bpf: Отказ в создании карты типа BPF_MAP_TYPE_INODE_STORAGE, если подсистема BPF LSM не инициализирована
При установке параметра CONFIG_BPF_LSM=y карты хранения inode для BPF (BPF_MAP_TYPE_INODE_STORAGE) компилируются непосредственно в ядро. Однако, если подсистема BPF LSM явно не включена во время загрузки системы (например, отсутствует в параметре запуска "lsm="), функция lsm_prepare() никогда не выполняется для подсистемы BPF LSM.
В результате смещение блока безопасности inode для BPF (bpf_lsm_blob_sizes.lbs_inode) никогда не инициализируется и остается равным значению по умолчанию при компиляции, составляющему 8 байт, вместо того чтобы быть обновленным до корректного смещения после зарезервированной структуры struct rcu_head (обычно 16 байт или более).
Когда привилегированный пользователь создает и обновляет карту типа BPF_MAP_TYPE_INODE_STORAGE, функция bpf_inode() вычисляет значение inode->i_security + 8. Это ошибочно приводит к алиасингу указателя обратного вызова struct rcu_head.func в начале блока inode->i_security. Во время последующей очистки элементов карты или уничтожения inode запись значения NULL в owner_storage очищает запланированный указатель обратного вызова RCU. Когда позже выполняется функция rcu_do_batch(), она пытается выполнить выборку инструкции по адресу 0x0, что вызывает немедленный паник ядра (kernel panic).
Исправление заключается во введении глобального булевого флага bpf_lsm_initialized с атрибутом __ro_after_init. Этот флаг устанавливается в true внутри функции bpf_lsm_init() при успешной регистрации подсистемы BPF LSM инфраструктурой LSM. Выделение карты в inode_storage_map_alloc() блокируется этим флагом, и возвращается код ошибки -EOPNOTSUPP, если подсистема BPF LSM не инициализирована.
Такой подход «быстрого отказа» (fail-fast) предотвращает выделение карт хранения inode из пространства пользователя при отсутствии поддерживающей инфраструктуры BPF LSM, избегая состояний «зомби-карт».
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.