CVSS: 5.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26974 – crypto: qat - resolve race condition during AER recovery
https://notcve.org/view.php?id=CVE-2024-26974
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat: resuelve la condición de ejecución durante la recuperación de AER Durante el proceso de recuperación de errores del sistema PCI AER, el controlador del kernel puede encontrar una condición de ejecución al liberar la memoria de la estructura reset_data. Si el reinicio del dispositivo demora más de 10 segundos, la función que programa el reinicio se cerrará debido a un tiempo de espera y se liberará la estructura reset_data. • https://git.kernel.org/stable/c/d8cba25d2c68992a6e7c1d329b690a9ebe01167d https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7 https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81 https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71 https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7 https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26973 – fat: fix uninitialized field in nostale filehandles
https://notcve.org/view.php?id=CVE-2024-26973
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fat: corrige el campo no inicializado en los identificadores de archivos notale Cuando fat_encode_fh_nostale() codifica el identificador de archivo sin un padre, almacena solo los primeros 10 bytes del identificador de archivo. • https://git.kernel.org/stable/c/ea3983ace6b79c96e6ab3d3837e2eaf81ab881e2 https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63 https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6 https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375 https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26966 – clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
https://notcve.org/view.php?id=CVE-2024-26966
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-apq8084: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado. • https://git.kernel.org/stable/c/2b46cd23a5a2cf0b8d3583338b63409f5e78e7cd https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2 https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0 https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9 https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99 https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03 https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26965 – clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
https://notcve.org/view.php?id=CVE-2024-26965
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-msm8974: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado. • https://git.kernel.org/stable/c/d8b212014e69d6b6323773ce6898f224ef4ed0d6 https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95 https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089 https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060 https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194 https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589 https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362 https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a5 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26962 – dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
https://notcve.org/view.php?id=CVE-2024-26962
In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todavía está en progreso, entonces IO en la posición de reshape esperará remodelar para progresar. • https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1 https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304 https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677 •