Описание
ELSA-2026-3464: kernel security update (MODERATE)
[4.18.0-553.109.1]
- Update Oracle Linux certificates (Kevin Lyons)
- Disable signing for aarch64 (Ilya Okomin)
- Oracle Linux RHCK Module Signing Key was added to the kernel trusted keys list (olkmod_signing_key.pem) [Orabug: 29539237]
- Update x509.genkey [Orabug: 24817676]
- Conflict with shim-ia32 and shim-x64 <= 15.3-1.0.3
- Remove upstream reference during boot (Kevin Lyons) [Orabug: 34750652]
- Add new Oracle Linux Driver Signing (key 1) certificate [Orabug: 37985772]
[4.18.0-553.109.1]
- migrate: correct lock ordering for hugetlb file folios (Luiz Capitulino) [RHEL-147261] {CVE-2026-23097}
[4.18.0-553.108.1]
- autofs: dont trigger mount if it cant succeed (Ian Kent) [RHEL-134673]
Обновленные пакеты
Oracle Linux 8
Oracle Linux aarch64
kernel-tools-libs-devel
4.18.0-553.109.1.el8_10
bpftool
4.18.0-553.109.1.el8_10
kernel-cross-headers
4.18.0-553.109.1.el8_10
kernel-headers
4.18.0-553.109.1.el8_10
kernel-tools
4.18.0-553.109.1.el8_10
kernel-tools-libs
4.18.0-553.109.1.el8_10
perf
4.18.0-553.109.1.el8_10
python3-perf
4.18.0-553.109.1.el8_10
Oracle Linux x86_64
kernel-tools-libs-devel
4.18.0-553.109.1.el8_10
bpftool
4.18.0-553.109.1.el8_10
kernel
4.18.0-553.109.1.el8_10
kernel-abi-stablelists
4.18.0-553.109.1.el8_10
kernel-core
4.18.0-553.109.1.el8_10
kernel-cross-headers
4.18.0-553.109.1.el8_10
kernel-debug
4.18.0-553.109.1.el8_10
kernel-debug-core
4.18.0-553.109.1.el8_10
kernel-debug-devel
4.18.0-553.109.1.el8_10
kernel-debug-modules
4.18.0-553.109.1.el8_10
kernel-debug-modules-extra
4.18.0-553.109.1.el8_10
kernel-devel
4.18.0-553.109.1.el8_10
kernel-doc
4.18.0-553.109.1.el8_10
kernel-headers
4.18.0-553.109.1.el8_10
kernel-modules
4.18.0-553.109.1.el8_10
kernel-modules-extra
4.18.0-553.109.1.el8_10
kernel-tools
4.18.0-553.109.1.el8_10
kernel-tools-libs
4.18.0-553.109.1.el8_10
perf
4.18.0-553.109.1.el8_10
python3-perf
4.18.0-553.109.1.el8_10
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes()...
In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes()...
In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing
In the Linux kernel, the following vulnerability has been resolved: m ...
