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: 7EXPL: 0CVE-2024-49855 – nbd: fix race between timeout and normal completion
https://notcve.org/view.php?id=CVE-2024-49855
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue. • https://git.kernel.org/stable/c/2895f1831e911ca87d4efdf43e35eb72a0c7e66e https://git.kernel.org/stable/c/cdf62c535a9bfd5ff0eef4b91669da39d8abc0c3 https://git.kernel.org/stable/c/5171ef20bae852ff38f4cfdb368bcdcc744776d0 https://git.kernel.org/stable/c/9c25faf72d780a9c71081710cd48759d61ff6e9b https://git.kernel.org/stable/c/6e73b946a379a1dfbb62626af93843bdfb53753d https://git.kernel.org/stable/c/5236ada8ebbd9e7461f17477357582f5be4f46f7 https://git.kernel.org/stable/c/9a74c3e6c0d686c26ba2aab66d15ddb89dc139cc https://git.kernel.org/stable/c/c9ea57c91f03bcad415e1a20113bdb207 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 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/9e813033594b141f61ff0ef0cfaaef292564b041 https://git.kernel.org/stable/c/3a5f45a4ad4e1fd36b0a998eef03d76a4f02a2a8 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/cae58d19121a70329cf971359e2518c93 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49853 – firmware: arm_scmi: Fix double free in OPTEE transport
https://notcve.org/view.php?id=CVE-2024-49853
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack. • https://git.kernel.org/stable/c/5f90f189a052f6fc46048f6ce29a37b709548b81 https://git.kernel.org/stable/c/d7f4fc2bc101e666da649605a9ece2bd42529c7a https://git.kernel.org/stable/c/6699567b0bbb378600a4dc0a1f929439a4e84a2c https://git.kernel.org/stable/c/dc9543a4f2a5498a4a12d6d2427492a6f1a28056 https://git.kernel.org/stable/c/aef6ae124bb3cc12e34430fed91fbb7efd7a444d https://git.kernel.org/stable/c/e98dba934b2fc587eafb83f47ad64d9053b18ae0 •
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 •