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-42154 – tcp_metrics: validate source addr length
https://notcve.org/view.php?id=CVE-2024-42154
In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated). • https://git.kernel.org/stable/c/3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9 https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98 https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6 https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3 https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99 https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7 •
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 •