Page 112 of 6098 results (0.005 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address. • https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914 https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93 https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72 https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a53 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. • https://git.kernel.org/stable/c/f83fca0707c66e36f14efef7f68702cb12de70b7 https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1 https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18 https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49 https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. • https://git.kernel.org/stable/c/8e0c5ebde82b08f6d996e11983890fc4cc085fab https://git.kernel.org/stable/c/d237c7d06ffddcdb5d36948c527dc01284388218 https://git.kernel.org/stable/c/564e1986b00c5f05d75342f8407f75f0a17b94df https://git.kernel.org/stable/c/9e96dea7eff6f2bbcd0b42a098012fc66af9eb69 https://git.kernel.org/stable/c/85449b28ff6a89c4513115e43ddcad949b5890c9 https://git.kernel.org/stable/c/60962c3d8e18e5d8dfa16df788974dd7f35bd87a https://git.kernel.org/stable/c/8a3995a3ffeca280a961b59f5c99843d81b15929 https://git.kernel.org/stable/c/4b540ec7c0045c2d01c4e479f34bbc8f1 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success. • https://git.kernel.org/stable/c/2661081f5ab9cb25359d27f88707a018cf4e68e9 https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9 https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06 https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6 https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63 https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. • https://git.kernel.org/stable/c/5e2b17e712cf10cc3cc98fde28a88e8f1a1267e9 https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8 https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118 https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246 https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51 •