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: 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: 4EXPL: 0CVE-2024-50187 – drm/vc4: Stop the active perfmon before being destroyed
https://notcve.org/view.php?id=CVE-2024-50187
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. • https://git.kernel.org/stable/c/65101d8c9108201118efa7e08f4e2c57f438deb9 https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967 https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0 https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513 https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50184 – virtio_pmem: Check device status before requesting flush
https://notcve.org/view.php?id=CVE-2024-50184
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. • https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36 https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4 https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4 https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50183 – scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
https://notcve.org/view.php?id=CVE-2024-50183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. • https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6 https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9 https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8 •