CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35809 – PCI/PM: Drain runtime-idle callbacks before driver removal
https://notcve.org/view.php?id=CVE-2024-35809
In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. • https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6 https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1 https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491 https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674 https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989 https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5 https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35808 – md/dm-raid: don't call md_reap_sync_thread() directly
https://notcve.org/view.php?id=CVE-2024-35808
In the Linux kernel, the following vulnerability has been resolved: md/dm-raid: don't call md_reap_sync_thread() directly Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'. However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/dm-raid: no llame a md_reap_sync_thread() directamente Actualmente, se llama a md_reap_sync_thread() desde raid_message() directamente sin mantener presionado 'reconfig_mutex', esto definitivamente no es seguro porque md_reap_sync_thread( ) puede cambiar muchos campos protegidos por 'reconfig_mutex'. Sin embargo, mantener 'reconfig_mutex' aquí sigue siendo problemático porque esto causará un punto muerto, por ejemplo, confirme 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Solucione este problema usando stop_sync_thread() para cancelar el registro de sync_thread, como lo hizo md/raid. • https://git.kernel.org/stable/c/be83651f0050ca8621d58d35dad558e9c45cb18f https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669 https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35807 – ext4: fix corruption during on-line resize
https://notcve.org/view.php?id=CVE-2024-35807
In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. • https://git.kernel.org/stable/c/01f795f9e0d67adeccc61a8b20c28acb45fa5fd8 https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6 https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5 https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d0 •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-35806 – soc: fsl: qbman: Always disable interrupts when taking cgr_lock
https://notcve.org/view.php?id=CVE-2024-35806
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: soc:fsl:qbman: Desactiva siempre las interrupciones al tomar cgr_lock smp_call_function_single desactiva las IRQ al ejecutar la devolución de llamada. Para evitar interbloqueos, debemos desactivar las IRQ cuando llevemos cgr_lock a otro lugar. Esto ya lo hacen qman_update_cgr y qman_delete_cgr; arreglar los otros casilleros. • https://git.kernel.org/stable/c/96f413f47677366e0ae03797409bfcc4151dbf9e https://git.kernel.org/stable/c/a85c525bbff4d7467d7f0ab6fed8e2f787b073d6 https://git.kernel.org/stable/c/29cd9c2d1f428c281962135ea046a9d7bda88d14 https://git.kernel.org/stable/c/5b10a404419f0532ef3ba990c12bebe118adb6d7 https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9 https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35805 – dm snapshot: fix lockup in dm_exception_table_exit
https://notcve.org/view.php?id=CVE-2024-35805
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm snapshot: corregido el bloqueo en dm_exception_table_exit Se informó un bloqueo cuando salimos de un snapshot con muchas excepciones. Solucione este problema agregando "cond_resched" al bucle que libera las excepciones. • https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7 https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1 https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2 https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366 https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683 https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef285 •