CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47667 – PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
https://notcve.org/view.php?id=CVE-2024-47667
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf • https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6 https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246 https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881 https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61 https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572 https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47666 – scsi: pm80xx: Set phy->enable_completion only when we wait for it
https://notcve.org/view.php?id=CVE-2024-47666
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. • https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89 https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84 https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47665 – i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup
https://notcve.org/view.php?id=CVE-2024-47665
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL. • https://git.kernel.org/stable/c/cacb76df247a7cd842ff29755a523b1cba6c0508 https://git.kernel.org/stable/c/2666085335bdfedf90d91f4071490ad3980be785 https://git.kernel.org/stable/c/5a022269abb22809f2a174b90f200fc4b9526058 https://git.kernel.org/stable/c/e2d14bfda9eb5393f8a17008afe2aa7fe0a29815 https://git.kernel.org/stable/c/8a2be2f1db268ec735419e53ef04ca039fc027dc •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47664 – spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
https://notcve.org/view.php?id=CVE-2024-47664
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned. • https://git.kernel.org/stable/c/16ccaf581da4fcf1e4d66086cf37263f9a656d43 https://git.kernel.org/stable/c/ee73a15d4a8ce8fb02d7866f7cf78fcdd16f0fcc https://git.kernel.org/stable/c/5127c42c77de18651aa9e8e0a3ced190103b449c •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47663 – staging: iio: frequency: ad9834: Validate frequency parameter value
https://notcve.org/view.php?id=CVE-2024-47663
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/12b9d5bf76bfa20d3207ef24fca9c8254a586a58 https://git.kernel.org/stable/c/0e727707a239d5c519fc9abc2f0fd913516a7e47 https://git.kernel.org/stable/c/41cc91e3138fe52f8da92a81bebcd0e6cf488c53 https://git.kernel.org/stable/c/d8b09a5edc4a634373158c1a405491de3c52e58a https://git.kernel.org/stable/c/3ba9abfcaa9e16bb91ed7e0e2b42e94a157a953e https://git.kernel.org/stable/c/dc12e49f970b08d8b007b8981b97e2eb93c0e89d https://git.kernel.org/stable/c/8961b245e8f92bccbaacfbbdf69eba60e3e7c227 https://git.kernel.org/stable/c/b48aa991758999d4e8f9296c5bbe388f2 •