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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35804 – KVM: x86: Mark target gfn of emulated atomic instruction as dirty
https://notcve.org/view.php?id=CVE-2024-35804
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: marcar el gfn de destino de la instrucción atómica emulada como sucia Al emular un acceso atómico en nombre del invitado, marque el gfn de destino como sucio si se intenta realizar el CMPXCHG por KVM y no falla. • https://git.kernel.org/stable/c/d97c0667c1e61ded6639117b4b9584a9c12b7e66 https://git.kernel.org/stable/c/1c2361f667f3648855ceae25f1332c18413fdb9f https://git.kernel.org/stable/c/b0f294103f4cf733e23d3f0c4e5fd58e42998921 https://git.kernel.org/stable/c/e964665cc7ca13a16992b205fce63554b9efc78b https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66 https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06 https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551 https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd •