Vlastimil Babka

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue arises in the `split large buddy()` function where `pfn to page()` might be called on a possibly non-existent PFN. In specific corner cases, such as freeing the highest pageblock in the last memory section with `CONFIG SPARSEMEM` and `!CONFIG SPARSEMEM EXTREME`, this could lead to ` pfn to section()` returning `NULL` and ` section mem map addr()` dereferencing that `NULL` pointer. The problem was identified through code inspection. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.8.0-rc3-1.gae4495f-default **Description** The issue is related to the wifi: ath11k component in the Linux kernel, where the buf len field of ath11k mhi config qca6390 is assigned a value of 0, causing MHI to use a default size of 64KB to allocate channel buffers. This can lead to page allocation failures in scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed. The largest packet size for QMI target -> host communication is less than 6KB for WCN6855 and QCA6390. To mitigate this, the buf len field is changed to 8KB, resulting in order 1 allocation if the page size is 4KB, which can save memory and decrease the possibility of allocation failure. **Recommendations** For Linux kernel versions prior to 6.8.0-rc3-1.gae4495f-default, update the kernel to a version that includes the fix for the wifi: ath11k component, where the buf len field of ath11k mhi config qca6390 is changed to 8KB. As a temporary workaround, consider restricting the use of the vulnerable component to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.1.0-rc5+ **Description** The issue is related to the tpm pm suspend() function in the Linux kernel, which may lead to races with other tpm accessors in the system. Specifically, the hw random tpm driver makes use of tpm get random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. The function `tpm pm suspend()` is vulnerable, and the `tpm get random()` function is called in a loop from a kthread. To fix this, the `tpm try get ops()` function is called, which itself is a wrapper around `tpm chip start()`, but takes the appropriate mutex. **Recommendations** For Linux kernel versions prior to 6.1.0-rc5+, consider updating to a newer version to mitigate the risk. As a temporary workaround, consider disabling the `tpm pm suspend()` function until a patch is available. Restrict access to the `tpm get random()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the `flush all cpu locked()` function in the Linux kernel's memory management subsystem. When this function is called from a task context, it may cause a dependency issue if a workqueue with the `WQ MEM RECLAIM` bit set ends up flushing the global workqueue. This can lead to problems with memory management and potentially affect the confidentiality, integrity, and availability of protected information. The vulnerability can be exploited by creating a workqueue for the flush operation without the `WQ MEM RECLAIM` bit set. **Recommendations** To resolve this issue, create a workqueue for the flush operation with the `WQ MEM RECLAIM` bit set. This will help avoid the dependency issue and ensure proper memory management. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a deadlock in the Linux kernel's vmscan component, which can cause a soft lockup. This occurs when kcompactd is not rescheduling on a CPU while a task is waiting for it to reschedule, allowing pages to be released. The problem is specific to CONFIG PREEMPT=n builds and can happen when there is no file LRU and the inactive anon list is not low. A task migrating pages was found to be trying to drain PCP lists, leading to the deadlock. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.