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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49856 – x86/sgx: Fix deadlock in SGX NUMA node search
https://notcve.org/view.php?id=CVE-2024-49856
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will. • https://git.kernel.org/stable/c/901ddbb9ecf5425183ea0c09d10c2fd7868dce54 https://git.kernel.org/stable/c/40fb64257dab507d86b5f1f2a62f3669ef0c91a8 https://git.kernel.org/stable/c/20c96d0aaabfe361fc2a11c173968dc67feadbbf https://git.kernel.org/stable/c/fb2d057539eda67ec7cfc369bf587e6518a9b99d https://git.kernel.org/stable/c/0f89fb4042c08fd143bfc28af08bf6c8a0197eea https://git.kernel.org/stable/c/8132510c915815e6b537ab937d94ed66893bc7b8 https://git.kernel.org/stable/c/9c936844010466535bd46ea4ce4656ef17653644 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49852 – scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()
https://notcve.org/view.php?id=CVE-2024-49852
In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees "nport". But then we dereference "nport" on the next line which is a use after free. Re-order these lines to avoid the use after free. • https://git.kernel.org/stable/c/fcd427303eb90aa3cb08e7e0b68e0e67a6d47346 https://git.kernel.org/stable/c/16a570f07d870a285b0c0b0d1ca4dff79e8aa5ff https://git.kernel.org/stable/c/abc71e89170ed32ecf0a5a29f31aa711e143e941 https://git.kernel.org/stable/c/baeb8628ab7f4577740f00e439d3fdf7c876b0ff https://git.kernel.org/stable/c/7c2908985e4ae0ea1b526b3916de9e5351650908 https://git.kernel.org/stable/c/98752fcd076a8cbc978016eae7125b4971be1eec https://git.kernel.org/stable/c/2e4b02fad094976763af08fec2c620f4f8edd9ae •