CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50194 – arm64: probes: Fix uprobes for big-endian kernels
https://notcve.org/view.php?id=CVE-2024-50194
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # . • https://git.kernel.org/stable/c/9842ceae9fa8deae141533d52a6ead7666962c09 https://git.kernel.org/stable/c/b6a638cb600e13f94b5464724eaa6ab7f3349ca2 https://git.kernel.org/stable/c/e6ab336213918575124d6db43dc5d3554526242e https://git.kernel.org/stable/c/cf9ddf9ed94c15564a05bbf6e9f18dffa0c7df80 https://git.kernel.org/stable/c/cf60d19d40184e43d9a624e55a0da73be09e938d https://git.kernel.org/stable/c/14841bb7a531b96e2dde37423a3b33e75147c60d https://git.kernel.org/stable/c/8165bf83b8a64be801d59cd2532b0d1ffed74d00 https://git.kernel.org/stable/c/3d2530c65be04e93720e30f191a7cf1a3 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50193 – x86/entry_32: Clear CPU buffers after register restore in NMI return
https://notcve.org/view.php?id=CVE-2024-50193
In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. • https://git.kernel.org/stable/c/50f021f0b985629accf10481a6e89af8b9700583 https://git.kernel.org/stable/c/d54de9f2a127090f2017184e8257795b487d5312 https://git.kernel.org/stable/c/2e3087505ddb8ba2d3d4c81306cca11e868fcdb9 https://git.kernel.org/stable/c/ca13d8cd8dac25558da4ee8df4dc70e8e7f9d762 https://git.kernel.org/stable/c/a0e2dab44d22b913b4c228c8b52b2a104434b0b3 https://git.kernel.org/stable/c/51eca9f1fd047b500137d021f882d93f03280118 https://git.kernel.org/stable/c/6f44a5fc15b5cece0785bc07453db77d99b0a6de https://git.kernel.org/stable/c/b6400eb0b347821efc57760221f8fb6d6 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50192 – irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
https://notcve.org/view.php?id=CVE-2024-50192
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. • https://git.kernel.org/stable/c/64edfaa9a2342a3ce34f8cb982c2c2df84db4de3 https://git.kernel.org/stable/c/b7d7b7fc876f836f40bf48a87e07ea18756ba196 https://git.kernel.org/stable/c/755b9532c885b8761fb135fedcd705e21e61cccb https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff https://git.kernel.org/stable/c/d960505a869e66184fff97fb334980a5b797c7c6 https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a https://access.redhat.com/security/cve/CVE-2024-50192 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50191 – ext4: don't set SB_RDONLY after filesystem errors
https://notcve.org/view.php?id=CVE-2024-50191
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that. • https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439 https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9 https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09 https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50189 – HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
https://notcve.org/view.php?id=CVE-2024-50189
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. • https://git.kernel.org/stable/c/4b2c53d93a4bc9d52cc0ec354629cfc9dc217f93 https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276 https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93 https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47 https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3 https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3 •