Vlastimil Babka

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.

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.

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.

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.

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.