Описание
ELSA-2017-2801: kernel security update (IMPORTANT)
kernel
-
2.6.18-419.0.0.0.4
-
[fs] fix bug in loading of PIE binaries (Michael Davidson) [orabug 26916951] {CVE-2017-1000253}
-
2.6.18-419.0.0.0.3
-
nfsd: stricter decoding of write-like NFSv2/v3 ops (J. Bruce Fields) [orabug 26586706] {CVE-2017-7895}
Обновленные пакеты
Oracle Linux 5
Oracle Linux x86_64
kernel
2.6.18-419.0.0.0.4.el5
kernel-debug
2.6.18-419.0.0.0.4.el5
kernel-debug-devel
2.6.18-419.0.0.0.4.el5
kernel-devel
2.6.18-419.0.0.0.4.el5
kernel-doc
2.6.18-419.0.0.0.4.el5
kernel-headers
2.6.18-419.0.0.0.4.el5
kernel-xen
2.6.18-419.0.0.0.4.el5
kernel-xen-devel
2.6.18-419.0.0.0.4.el5
ocfs2-2.6.18-419.0.0.0.4.el5
1.4.11-1.el5
ocfs2-2.6.18-419.0.0.0.4.el5debug
1.4.11-1.el5
ocfs2-2.6.18-419.0.0.0.4.el5xen
1.4.11-1.el5
oracleasm-2.6.18-419.0.0.0.4.el5
2.0.5-2.el5
oracleasm-2.6.18-419.0.0.0.4.el5debug
2.0.5-2.el5
oracleasm-2.6.18-419.0.0.0.4.el5xen
2.0.5-2.el5
Oracle Linux i386
kernel
2.6.18-419.0.0.0.4.el5
kernel-PAE
2.6.18-419.0.0.0.4.el5
kernel-PAE-devel
2.6.18-419.0.0.0.4.el5
kernel-debug
2.6.18-419.0.0.0.4.el5
kernel-debug-devel
2.6.18-419.0.0.0.4.el5
kernel-devel
2.6.18-419.0.0.0.4.el5
kernel-doc
2.6.18-419.0.0.0.4.el5
kernel-headers
2.6.18-419.0.0.0.4.el5
kernel-xen
2.6.18-419.0.0.0.4.el5
kernel-xen-devel
2.6.18-419.0.0.0.4.el5
ocfs2-2.6.18-419.0.0.0.4.el5
1.4.11-1.el5
ocfs2-2.6.18-419.0.0.0.4.el5PAE
1.4.11-1.el5
ocfs2-2.6.18-419.0.0.0.4.el5debug
1.4.11-1.el5
ocfs2-2.6.18-419.0.0.0.4.el5xen
1.4.11-1.el5
oracleasm-2.6.18-419.0.0.0.4.el5
2.0.5-2.el5
oracleasm-2.6.18-419.0.0.0.4.el5PAE
2.0.5-2.el5
oracleasm-2.6.18-419.0.0.0.4.el5debug
2.0.5-2.el5
oracleasm-2.6.18-419.0.0.0.4.el5xen
2.0.5-2.el5
Связанные CVE
Связанные уязвимости
Linux distributions that have not patched their long-term kernels with https://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (committed on April 14, 2015). This kernel vulnerability was fixed in April 2015 by commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in May 2015), but it was not recognized as a security threat. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary.
Linux distributions that have not patched their long-term kernels with https://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (committed on April 14, 2015). This kernel vulnerability was fixed in April 2015 by commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in May 2015), but it was not recognized as a security threat. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary.
Linux distributions that have not patched their long-term kernels with https://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (committed on April 14, 2015). This kernel vulnerability was fixed in April 2015 by commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in May 2015), but it was not recognized as a security threat. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary.
Linux distributions that have not patched their long-term kernels with ...
