CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26674 – x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups
https://notcve.org/view.php?id=CVE-2024-26674
In the Linux kernel, the following vulnerability has been resolved: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups During memory error injection test on kernels >= v6.4, the kernel panics like below. However, this issue couldn't be reproduced on kernels <= v6.3. mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20} mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86 mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The MCA code can recover from an in-kernel #MC if the fixup type is EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT the only thing that is raised for an in-kernel #MC is a panic. ex_handler_uaccess() would warn if users gave a non-canonical addresses (with bit 63 clear) to {get, put}_user(), which was unexpected. Therefore, commit b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()") replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user() fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic. Commit 6014bc27561f ("x86-64: make access_ok() independent of LAM") added the check gp_fault_address_ok() right before the WARN_ONCE() in ex_handler_uaccess() to not warn about non-canonical user addresses due to LAM. With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user() exception fixups in order to be able to handle in-kernel MCEs correctly again. [ bp: Massage commit message. ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/lib: vuelva a _ASM_EXTABLE_UA() para reparaciones de {get,put}_user() Durante la prueba de inyección de errores de memoria en kernels >= v6.4, el kernel entra en pánico como se muestra a continuación. Sin embargo, este problema no se pudo reproducir en kernels <= v6.3. mce: [Error de hardware]: CPU 296: Excepción de verificación de la máquina: f Banco 1: bd80000000100134 mce: [Error de hardware]: RIP 10: {__get_user_nocheck_4+0x6/0x20} mce: [Error de hardware]: TSC 411a93533ed ADDR 346a87300 40 MISC 86 mce: [Error de hardware]: PROCESADOR 0:a06d0 HORA 1706000767 SOCKET 1 APIC 211 microcódigo 80001490 mce: [Error de hardware]: Ejecute lo anterior a través de 'mcelog --ascii' mce: [Error de hardware]: Verificación de la máquina: Carga de datos en un área irrecuperable del kernel Pánico del kernel - no se sincroniza: verificación fatal de la máquina local El código MCA se puede recuperar de un #MC en el kernel si el tipo de reparación es EX_TYPE_UACCESS, lo que indica explícitamente que el kernel está intentando acceder a la memoria del espacio de usuario. • https://git.kernel.org/stable/c/b19b74bc99b1501a550f4448d04d59b946dc617a https://git.kernel.org/stable/c/2aed1b6c33afd8599d01c6532bbecb829480a674 https://git.kernel.org/stable/c/2da241c5ed78d0978228a1150735539fe1a60eca https://git.kernel.org/stable/c/8eed4e00a370b37b4e5985ed983dccedd555ea9d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52636 – libceph: just wait for more data to be available on the socket
https://notcve.org/view.php?id=CVE-2023-52636
In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. • https://git.kernel.org/stable/c/d396f89db39a2f259e2125ca43b4c31bb65afcad https://git.kernel.org/stable/c/da9c33a70f095d5d55c36d0bfeba969e31de08ae https://git.kernel.org/stable/c/bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8 https://git.kernel.org/stable/c/8e46a2d068c92a905d01cbb018b00d66991585ab •
CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26673 – netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
https://notcve.org/view.php?id=CVE-2024-26673
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_ct: desinfecta el número de protocolo de capa 3 y 4 en expectativas personalizadas - No permitir familias que no sean NFPROTO_{IPV4,IPV6,INET}. - No permitir el protocolo de capa 4 sin puertos, ya que el puerto de destino es un atributo obligatorio para este objeto. • https://git.kernel.org/stable/c/857b46027d6f91150797295752581b7155b9d0e1 https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483 https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98 https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8 https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26672 – drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'
https://notcve.org/view.php?id=CVE-2024-26672
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la variable 'mca_funcs' desreferenciada antes de la comprobación NULL en 'amdgpu_mca_smu_get_mca_entry()' Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() advertencia: variable desreferenciada antes de verificar 'mca_funcs' (ver línea 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev- >mca.mca_funcs; 361 recuentos internacionales; 362 363 interruptor (tipo) { 364 caso AMDGPU_MCA_ERROR_TYPE_UE: 365 recuento = mca_funcs->max_ue_count; Aquí se elimina la referencia a mca_funcs. 366 descanso; 367 caso AMDGPU_MCA_ERROR_TYPE_CE: 368 recuento = mca_funcs->max_ce_count; Aquí se elimina la referencia a mca_funcs. 369 descanso; 370 predeterminado: 371 retorno -EINVAL; 372 } 373 374 si (idx >= recuento) 375 retorno -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ ¡Comprobado demasiado tarde! • https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53 https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26671 – blk-mq: fix IO hang from sbitmap wakeup race
https://notcve.org/view.php?id=CVE-2024-26671
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: corrige el bloqueo de IO de la carrera de activación del mapa de bits En blk_mq_mark_tag_wait(), __add_wait_queue() se puede reordenar con el siguiente blk_mq_get_driver_tag() en caso de que se produzca un error en la etiqueta del controlador. Luego, en __sbitmap_queue_wake_up(), waitqueue_active() puede no observar al camarero agregado en blk_mq_mark_tag_wait() y no despertar nada, mientras tanto, blk_mq_mark_tag_wait() no puede obtener la etiqueta del controlador correctamente. Este problema se puede reproducir ejecutando la siguiente prueba en bucle, y se puede observar un bloqueo de fio en < 30 minutos cuando lo ejecuto en mi máquina virtual de prueba en una computadora portátil. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block /* | cabeza -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --io Depth=1 \ --runtime=100 --numjobs=40 --time_based - -name=test \ --ioengine=libaio Solucione el problema agregando una barrera explícita en blk_mq_mark_tag_wait(), lo cual está bien en caso de quedarse sin etiqueta. • https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676 https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10 https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56 https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0 https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2 https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174ca • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •