В ядре Linux устранена следующая уязвимость:
ocfs2/dlm: требуется ссылка для открытия locking_state debugfs
debug_lockres_open() копирует inode->i_private в структуру debug_lockres и
debug_lockres_release() позже удаляет этот указатель с помощью dlm_put(). Это
работает только в том случае, если открытие успешно закрепляет структуру dlm_ctxt. Сегодня open вызывает dlm_grab(dlm), но игнорирует возвращаемое значение.
Как только
последняя отмена регистрации домена удалила контекст из dlm_domains,
dlm_grab() возвращает NULL, но open по-прежнему сохраняет необработанный указатель и возвращает
успех. Путь более позднего выпуска находится за пределами барьера удаления debugfs,
поэтому он может вызвать dlm_put() после того, как dlm_free_ctxt_mem() освободит контекст.
KASAN сообщает об этом как о slab-use-after-free в dlm_put(), вызываемом из
debug_lockres_release(). Ошибка открытия, когда dlm_grab() не может получить ссылку и развернуть
личное состояние seq_file перед возвратом.
Это удерживает locking_state от
выдача файлового дескриптора, путь выпуска которого не владеет
dlm_ctxt. Сценарий с ошибкой включает в себя два пути, где в каждом столбце указан порядок
внутри этого пути:
locking_state debugfs open: отмена регистрации последнего домена:
1. debug_lockres_open() читает 1. вызывает dlm_unregister_domain()
индексный дескриптор->i_private. dlm_complete_dlm_shutdown().
2. вызывает debug_lockres_open() 2. завершение работы удаляет dlm_ctxt из
dlm_grab(dlm) и получает NULL. dlm_domains.
3. open все еще хранит необработанные файлы dlm 3. достигается окончательный разбор
указатель в dl->dl_ctxt и dlm_free_ctxt_mem() и освобождает его.
возвращает успех.
4. debug_lockres_release() позже
вызывает dlm_put(dl->dl_ctxt). Проверка воспроизвела этот отчет ядра:
KASAN slab-use-after-free в dlm_put+0x82/0x200
РИП: 0033:0x7f4d349bc9e0
Адрес ошибки принадлежит объекту по адресу ffff888103a3c000, который принадлежит
в кеш kmalloc-2k размером 2048
Адрес ошибки расположен в 816 байтах внутри освобожденной 2048-байтовой области.
[ffff888103a3c000, ffff888103a3c800)
Пишите размера 4.
Трассировка звонков:
dump_stack_lvl+0x66/0xa0 (?:?)
print_report+0xd0/0x630 (?:?)
dlm_put+0x82/0x200 (?:?)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
__virt_addr_valid+0x188/0x2f0 (?:?)
kasan_report+0xe4/0x120 (?:?)
kasan_check_range+0x105/0x1b0 (?:?)
debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587)
dlm_put+0x9/0x200 (?:?)
debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587)
full_proxy_release+0x67/0x90 (?:?)
__fput+0x1df/0x4b0 (?:?)
do_raw_spin_lock+0x10f/0x1b0 (?:?)
fput_close_sync+0xd2/0x170 (?:?)
__x64_sys_close+0x55/0x90 (?:?)
do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87)
irqentry_exit+0xac/0x6e0 (?:?)
запись_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
Освобождается стеком задач:
kasan_save_stack+0x33/0x60 (?:?)
kasan_save_track+0x14/0x30 (?:?)
kasan_save_free_info+0x3b/0x60 (?:?)
__kasan_slab_free+0x5f/0x80 (?:?)
kfree+0x30f/0x580 (?:?)
dlm_put+0x1ce/0x200 (?:?)
dlm_unregister_domain+0xf6/0xb30 (?:?)
o2cb_cluster_disconnect+0x6b/0x90 (?:?)
ocfs2_cluster_disconnect+0x41/0x70 (?:?)
ocfs2_dlm_shutdown+0x1c4/0x220 (?:?)
ocfs2_dismount_volume+0x38a/0x550 (?:?)
generic_shutdown_super+0xc3/0x220 (?:?)
kill_block_super+0x29/0x60 (?:?)
deactivate_locked_super+0x66/0xe0 (?:?)
Cleanup_mnt+0x13d/0x210 (?:?)
Task_work_run+0xfa/0x170 (?:?)
exit_to_user_mode_loop+0xd6/0x430 (?:?)
do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87)
запись_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)