An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2024-2449 Final 1.0 1.0 2024-11-22 Initial 2024-11-22 2024-11-22 openEuler SA Tool V1.0 2024-11-22 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks](CVE-2024-47745) In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115) In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)(CVE-2024-50117) In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195) In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237) An update for kernel is now available for openEuler-20.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-47745 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50115 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50117 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50195 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50237 https://nvd.nist.gov/vuln/detail/CVE-2024-47745 https://nvd.nist.gov/vuln/detail/CVE-2024-50115 https://nvd.nist.gov/vuln/detail/CVE-2024-50117 https://nvd.nist.gov/vuln/detail/CVE-2024-50195 https://nvd.nist.gov/vuln/detail/CVE-2024-50237 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm perf-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.x86_64.rpm kernel-4.19.90-2411.4.0.0304.oe2003sp4.src.rpm bpftool-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm perf-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2411.4.0.0304.oe2003sp4.aarch64.rpm In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] 2024-11-22 CVE-2024-47745 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2024-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449 In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken. 2024-11-22 CVE-2024-50115 openEuler-20.03-LTS-SP4 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2024-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449 In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee) 2024-11-22 CVE-2024-50117 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449 In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. 2024-11-22 CVE-2024-50195 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449 In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data 2024-11-22 CVE-2024-50237 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-11-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2449