CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42157 – s390/pkey: Wipe sensitive data on failure
https://notcve.org/view.php?id=CVE-2024-42157
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe sensitive data on failure Wipe sensitive data from stack also if the copy_to_user() fails. • https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02 https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250 https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581 https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0 https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487 https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575 https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a57 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42156 – s390/pkey: Wipe copies of clear-key structures on failure
https://notcve.org/view.php?id=CVE-2024-42156
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe copies of clear-key structures on failure Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key. • https://git.kernel.org/stable/c/7f6243edd901b75aaece326c90a1cc0dcb60cc3d https://git.kernel.org/stable/c/d65d76a44ffe74c73298ada25b0f578680576073 •
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: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42153 – i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
https://notcve.org/view.php?id=CVE-2024-42153
In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether. • https://git.kernel.org/stable/c/41561f28e76a47dc6de0a954da85d0b5c42874eb https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6 https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2 https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176 https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3 https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d •
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 •