Описание
ELSA-2024-12700: Unbreakable Enterprise kernel security update (IMPORTANT)
[4.1.12-124.90.3]
- SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int (Dai Ngo) [Orabug: 37055439]
[4.1.12-124.90.2]
- scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() (Justin Tee) [Orabug: 36643241] {CVE-2024-35930}
- scsi: qla2xxx: Fix command flush on cable pull (Quinn Tran) [Orabug: 36596617] {CVE-2024-26931}
- VMCI: Fix use-after-free when removing resource in vmci_resource_remove() (David Fernandez Gonzalez) [Orabug: 33917166]
[4.1.12-124.90.1]
- i40e: Do not use WQ_MEM_RECLAIM flag for workqueue (Sindhu Devale) [Orabug: 36643519] {CVE-2024-36004}
- dyndbg: fix old BUG_ON in >control parser (Jim Cromie) [Orabug: 36643340] {CVE-2024-35947}
- btrfs: send: handle path ref underflow in header iterate_inode_ref() (David Sterba) [Orabug: 36643269] {CVE-2024-35935}
- ipv6: Fix infinite recursion in fib6_dump_done(). (Kuniyuki Iwashima) [Orabug: 36643095] {CVE-2024-35886}
- x86/mm/pat: fix VM_PAT handling in COW mappings (David Hildenbrand) [Orabug: 36643059] {CVE-2024-35877}
Обновленные пакеты
Oracle Linux 6
Oracle Linux x86_64
kernel-uek
4.1.12-124.90.3.el6uek
kernel-uek-debug
4.1.12-124.90.3.el6uek
kernel-uek-debug-devel
4.1.12-124.90.3.el6uek
kernel-uek-devel
4.1.12-124.90.3.el6uek
kernel-uek-doc
4.1.12-124.90.3.el6uek
kernel-uek-firmware
4.1.12-124.90.3.el6uek
Oracle Linux 7
Oracle Linux x86_64
kernel-uek
4.1.12-124.90.3.el7uek
kernel-uek-debug
4.1.12-124.90.3.el7uek
kernel-uek-debug-devel
4.1.12-124.90.3.el7uek
kernel-uek-devel
4.1.12-124.90.3.el7uek
kernel-uek-doc
4.1.12-124.90.3.el7uek
kernel-uek-firmware
4.1.12-124.90.3.el7uek
Ссылки на источники
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mapp...
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW map...
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW
In the Linux kernel, the following vulnerability has been resolved: x ...