CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50198 – iio: light: veml6030: fix IIO device retrieval from embedded device
https://notcve.org/view.php?id=CVE-2024-50198
In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. • https://git.kernel.org/stable/c/7b779f573c48e1ad6da1d6ea5f181f3ecd666bf6 https://git.kernel.org/stable/c/bf3ab8e1c28f10df0823d4ff312f83c952b06a15 https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2 https://git.kernel.org/stable/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361 https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a https://git.kernel.org/stable/c/905166531831beb067fffe2bdfc98031ffe89087 https://git.kernel.org/stable/c/c7c44e57750c31de43906d97813273fdffcf7d02 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50196 – pinctrl: ocelot: fix system hang on level based interrupts
https://notcve.org/view.php?id=CVE-2024-50196
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` • https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6 https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417 https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381 https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50195 – posix-clock: Fix missing timespec64 check in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50195
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. • https://git.kernel.org/stable/c/0606f422b453f76c31ab2b1bd52943ff06a2dcf2 https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584 https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512 https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073 https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01 https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8 •
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: 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 •