CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53153 – PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()
https://notcve.org/view.php?id=CVE-2024-53153
In the Linux kernel, the following vulnerability has been resolved: PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert() Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of qcom_pcie_perst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the Qcom endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup functions are currently causing the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. • https://git.kernel.org/stable/c/570d7715eed8a29ac5bd96c7694f060a991e5a31 https://git.kernel.org/stable/c/e03b5f1615c84f4139cb53ef8659f4cdb8d6a563 https://git.kernel.org/stable/c/516969d5765e2302d33b4f251496eedb757d55ea https://git.kernel.org/stable/c/7d7cf89b119af433354f865fc01017b9f8aa411a •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53152 – PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
https://notcve.org/view.php?id=CVE-2024-53152
In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert() Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the tegra194 endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup functions can cause the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. • https://git.kernel.org/stable/c/570d7715eed8a29ac5bd96c7694f060a991e5a31 https://git.kernel.org/stable/c/70212c2300971506e986d95000d2745529cac9d7 https://git.kernel.org/stable/c/72034050ccf4202cd6558b0afd2474f756ea3b9b https://git.kernel.org/stable/c/40e2125381dc11379112485e3eefdd25c6df5375 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-53151 – svcrdma: Address an integer overflow
https://notcve.org/view.php?id=CVE-2024-53151
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 /* A bogus segcount causes this buffer overflow check to fail. */ > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode(). • https://git.kernel.org/stable/c/78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 https://git.kernel.org/stable/c/21e1cf688fb0397788c8dd42e1e0b08d58ac5c7b https://git.kernel.org/stable/c/c1f8195bf68edd2cef0f18a4cead394075a54b5a https://git.kernel.org/stable/c/838dd342962cef4c320632a5af48d3c31f2f9877 https://git.kernel.org/stable/c/4cbc3ba6dc2f746497cade60bcbaa82ae3696689 https://git.kernel.org/stable/c/e5c440c227ecdc721f2da0dd88b6358afd1031a7 https://git.kernel.org/stable/c/3c63d8946e578663b868cb9912dac616ea68bfd0 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-53150 – ALSA: usb-audio: Fix out of bounds reads when finding clock sources
https://notcve.org/view.php?id=CVE-2024-53150
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. • https://git.kernel.org/stable/c/a632bdcb359fd8145e86486ff8612da98e239acd https://git.kernel.org/stable/c/45a92cbc88e4013bfed7fd2ccab3ade45f8e896b https://git.kernel.org/stable/c/ab011f7439d9bbfd34fd3b9cef4b2d6d952c9bb9 https://git.kernel.org/stable/c/da13ade87a12dd58829278bc816a61bea06a56a9 https://git.kernel.org/stable/c/74cb86e1006c5437b1d90084d22018da30fddc77 https://git.kernel.org/stable/c/ea0fa76f61cf8e932d1d26e6193513230816e11d https://git.kernel.org/stable/c/096bb5b43edf755bc4477e64004fa3a20539ec2f https://git.kernel.org/stable/c/a3dd4d63eeb452cfb064a13862fb376ab •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53149 – usb: typec: ucsi: glink: fix off-by-one in connector_status
https://notcve.org/view.php?id=CVE-2024-53149
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: glink: fix off-by-one in connector_status UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS. Correct the condition in the pmic_glink_ucsi_connector_status() callback, fixing Type-C orientation reporting for the third USB-C connector. • https://git.kernel.org/stable/c/76716fd5bf09725c2c6825264147f16c21e56853 https://git.kernel.org/stable/c/9a5a8b5bd72169aa7a8ec800ef57be2f2cb4d9b2 https://git.kernel.org/stable/c/6ba6f7f29e0dff47a2799e60dcd1b5c29cd811a5 https://git.kernel.org/stable/c/4a22918810980897393fa1776ea3877e4baf8cca •