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: 1EXPL: 0CVE-2024-49854 – block, bfq: fix uaf for accessing waker_bfqq after splitting
https://notcve.org/view.php?id=CVE-2024-49854
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for accessing waker_bfqq after splitting After commit 42c306ed7233 ("block, bfq: don't break merge chain in bfq_split_bfqq()"), if the current procress is the last holder of bfqq, the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq may in the merge chain of bfqq, hence just recored waker_bfqq is still not safe. Fix the problem by adding a helper bfq_waker_bfqq() to check if bfqq->waker_bfqq is in the merge chain, and current procress is the only holder. • https://git.kernel.org/stable/c/3630a18846c7853aa326d3b42fd0a855af7b41bc https://git.kernel.org/stable/c/63a07379fdb6c72450cb05294461c6016b8b7726 https://git.kernel.org/stable/c/de0456460f2abf921e356ed2bd8da87a376680bd https://git.kernel.org/stable/c/0780451f03bf518bc032a7c584de8f92e2d39d7f https://git.kernel.org/stable/c/0b8bda0ff17156cd3f60944527c9d8c9f99f1583 https://git.kernel.org/stable/c/cae58d19121a70329cf971359e2518c93fec04fe https://git.kernel.org/stable/c/1ba0403ac6447f2d63914fb760c44a3b19c44eaf •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49851 – tpm: Clean up TPM space after command failure
https://notcve.org/view.php?id=CVE-2024-49851
In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure. • https://git.kernel.org/stable/c/745b361e989af21ad40811c2586b60229f870a68 https://git.kernel.org/stable/c/2c9b228938e9266a1065a3f4fe5c99b7235dc439 https://git.kernel.org/stable/c/ebc4e1f4492d114f9693950621b3ea42b2f82bec https://git.kernel.org/stable/c/c84ceb546f30432fccea4891163f7050f5bee5dd https://git.kernel.org/stable/c/82478cb8a23bd4f97935bbe60d64528c6d9918b4 https://git.kernel.org/stable/c/adf4ce162561222338cf2c9a2caa294527f7f721 https://git.kernel.org/stable/c/3f9f72d843c92fb6f4ff7460d774413cde7f254c https://git.kernel.org/stable/c/e3aaebcbb7c6b403416f442d1de70d437 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47757 – nilfs2: fix potential oob read in nilfs_btree_check_delete()
https://notcve.org/view.php?id=CVE-2024-47757
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case. • https://git.kernel.org/stable/c/17c76b0104e4a6513983777e1a17e0297a12b0c4 https://git.kernel.org/stable/c/d20674f31626e0596ae4c1d9401dfb6739b81b58 https://git.kernel.org/stable/c/c4f8554996e8ada3be872dfb8f60e93bcf15fb27 https://git.kernel.org/stable/c/a8abfda768b9f33630cfbc4af6c4214f1e5681b0 https://git.kernel.org/stable/c/257f9e5185eb6de83377caea686c306e22e871f2 https://git.kernel.org/stable/c/a33e967b681e088a125b979975c93e3453e686cd https://git.kernel.org/stable/c/c4cbcc64bb31e67e02940ce060cc77f7180564cf https://git.kernel.org/stable/c/f9c96351aa6718b42a9f42eaf7adce035 •