CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49862 – powercap: intel_rapl: Fix off by one in get_rpi()
https://notcve.org/view.php?id=CVE-2024-49862
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access. • https://git.kernel.org/stable/c/98ff639a7289067247b3ef9dd5d1e922361e7365 https://git.kernel.org/stable/c/288cbc505e2046638c615c36357cb78bc9fee1e0 https://git.kernel.org/stable/c/851e7f7f14a15f4e47b7d0f70d5c4a2b95b824d6 https://git.kernel.org/stable/c/6a34f3b0d7f11fb6ed72da315fd2360abd9c0737 https://git.kernel.org/stable/c/95f6580352a7225e619551febb83595bcb77ab17 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49861 – bpf: Fix helper writes to read-only maps
https://notcve.org/view.php?id=CVE-2024-49861
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in ! • https://git.kernel.org/stable/c/57c3bb725a3dd97d960d7e1cd0845d88de53217f https://git.kernel.org/stable/c/988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0 https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5 https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49860 – ACPI: sysfs: validate return type of _STR method
https://notcve.org/view.php?id=CVE-2024-49860
In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory. • https://git.kernel.org/stable/c/d1efe3c324ead77d3f6cd85093b50f6bd2e17aba https://git.kernel.org/stable/c/92fd5209fc014405f63a7db79802ca4b01dc0c05 https://git.kernel.org/stable/c/2364b6af90c6b6d8a4783e0d3481ca80af699554 https://git.kernel.org/stable/c/4b081991c4363e072e1748efed0bbec8a77daba5 https://git.kernel.org/stable/c/0cdfb9178a3bba843c95c2117c82c15f1a64b9ce https://git.kernel.org/stable/c/5c8d007c14aefc3f2ddf71e4c40713733dc827be https://git.kernel.org/stable/c/f0921ecd4ddc14646bb5511f49db4d7d3b0829f0 https://git.kernel.org/stable/c/f51e5a88f2e7224858b261546cf6b3037 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49859 – f2fs: fix to check atomic_file in f2fs ioctl interfaces
https://notcve.org/view.php?id=CVE-2024-49859
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it. • https://git.kernel.org/stable/c/26b07bd2e1f124b0e430c8d250023f7205c549c3 https://git.kernel.org/stable/c/7cb51731f24b216b0b87942f519f2c67a17107ee https://git.kernel.org/stable/c/10569b682ebe9c75ef06ddd322ae844e9be6374b https://git.kernel.org/stable/c/d6f08c88047accc6127dddb6798a3ff11321539d https://git.kernel.org/stable/c/bfe5c02654261bfb8bd9cb174a67f3279ea99e58 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49858 – efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
https://notcve.org/view.php?id=CVE-2024-49858
In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. • https://git.kernel.org/stable/c/f76b69ab9cf04358266e3cea5748c0c2791fbb08 https://git.kernel.org/stable/c/11690d7e76842f29b60fbb5b35bc97d206ea0e83 https://git.kernel.org/stable/c/5b22c038fb2757c652642933de5664da471f8cb7 https://git.kernel.org/stable/c/19fd2f2c5fb36b61506d3208474bfd8fdf1cada3 https://git.kernel.org/stable/c/38d9b07d99b789efb6d8dda21f1aaad636c38993 https://git.kernel.org/stable/c/2e6871a632a99d9b9e2ce3a7847acabe99e5a26e https://git.kernel.org/stable/c/77d48d39e99170b528e4f2e9fc5d1d64cdedd386 •