CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42155 – s390/pkey: Wipe copies of protected- and secure-keys
https://notcve.org/view.php?id=CVE-2024-42155
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe copies of protected- and secure-keys Although the clear-key of neither protected- nor secure-keys is accessible, this key material should only be visible to the calling process. So wipe all copies of protected- or secure-keys from stack, even in case of an error. • https://git.kernel.org/stable/c/c746f7ced4ad88ee48d0b6c92710e4674403185b https://git.kernel.org/stable/c/f2ebdadd85af4f4d0cae1e5d009c70eccc78c207 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42152 – nvmet: fix a possible leak when destroy a ctrl during qp establishment
https://notcve.org/view.php?id=CVE-2024-42152
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. • https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5 https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1 https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33 https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4 https://access.redhat.com/security/cve/CVE-2024-42152 https://bugzilla.redhat.com/show_bug.cgi?id=2301519 • CWE-404: Improper Resource Shutdown or Release •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42151 – bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable
https://notcve.org/view.php?id=CVE-2024-42151
In the Linux kernel, the following vulnerability has been resolved: bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first parameter of the test_1() function. Mark this parameter as nullable to make verifier aware of such possibility. Otherwise, NULL check in the test_1() code: SEC("struct_ops/test_1") int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { if (!state) return ...; ... access state ... } Might be removed by verifier, thus triggering NULL pointer dereference under certain conditions. • https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23 https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42147 – crypto: hisilicon/debugfs - Fix debugfs uninit process issue
https://notcve.org/view.php?id=CVE-2024-42147
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process. • https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3 https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42146 – drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf
https://notcve.org/view.php?id=CVE-2024-42146
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf Any kunit doing any memory access should get their own runtime_pm outer references since they don't use the standard driver API entries. In special this dma_buf from the same driver. Found by pre-merge CI on adding WARN calls for unprotected inner callers: <6> [318.639739] # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver <4> [318.639957] ------------[ cut here ]------------ <4> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection <4> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe] • https://git.kernel.org/stable/c/0888d15ea45ba8ef4508edd1123ea5ad95b58994 https://git.kernel.org/stable/c/f9116f658a6217b101e3b4e89f845775b6fb05d9 •