CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35810 – drm/vmwgfx: Fix the lifetime of the bo cursor memory
https://notcve.org/view.php?id=CVE-2024-35810
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix the lifetime of the bo cursor memory The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmw_plane_state instead of using the builtin map_and_cache were trying to handle the lifetime of the mapped memory themselves, leading to crashes. Use the map_and_cache instead of trying to manage the lifetime of the buffer objects held by the vmw_plane_state. Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: corregida la vida útil de la memoria del cursor bo. La sanitización se puede realizar mientras la actualización atómica aún está activa, lo que significa que la memoria adquirida en la actualización atómica no necesita ser invalidado por la limpieza. Los objetos del búfer en vmw_plane_state, en lugar de utilizar el map_and_cache incorporado, intentaban manejar ellos mismos la vida útil de la memoria asignada, lo que provocaba fallos. • https://git.kernel.org/stable/c/bb6780aa5a1d99e86757c0c96bfae65a46cf839e https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c https://git.kernel.org/stable/c/ed381800ea6d9a4c7f199235a471c0c48100f0ae https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76 https://access.redhat.com/security/cve/CVE-2024-35810 https://bugzilla.redhat.com/show_bug.cgi?id=2281215 •
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: 5.5EPSS: 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. A flaw was found in the `md/dm-raid` subsystem in the Linux kernel. • 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 https://access.redhat.com/security/cve/CVE-2024-35808 https://bugzilla.redhat.com/show_bug.cgi?id=2281219 •
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 •