OESA-2024-2449

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: mm: call the securitymmapfile() LSM hook in remapfilepages() The remapfilepages syscall handler calls dommap() directly, which doesn't contain the LSM security check. And if the process has called personality(READIMPLIESEXEC) before and remapfilepages() 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 securitymmapfile LSM hook in the remapfilepages syscall handler before dommap() 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) { sizet pagesz = sysconf(SCPAGESIZE); int mfd = syscall(SYSmemfdcreate, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROTREAD | PROTWRITE, MAPSHARED, mfd, 0); unsigned int old = syscall(SYSpersonality, 0xffffffff); syscall(SYSpersonality, READIMPLIESEXEC | old); syscall(SYSremapfilepages, buf, pagesz, 0, 2, 0); syscall(SYSpersonality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", ORDONLY); 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

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 pcclocksettime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64(). As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec 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 timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid. There are some drivers that use tp->tvsec and tp->tvnsec 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 hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), 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)