CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42257 – ext4: use memtostr_pad() for s_volume_name
https://notcve.org/view.php?id=CVE-2024-42257
In the Linux kernel, the following vulnerability has been resolved: ext4: use memtostr_pad() for s_volume_name As with the other strings in struct ext4_super_block, s_volume_name is not NUL terminated. The other strings were marked in commit 072ebb3bffe6 ("ext4: add nonstring annotations to ext4.h"). Using strscpy() isn't the right replacement for strncpy(); it should use memtostr_pad() instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: use memtostr_pad() para s_volume_name Al igual que con las otras cadenas en la estructura ext4_super_block, s_volume_name no tiene terminación NUL. Las otras cadenas se marcaron en el commit 072ebb3bffe6 ("ext4: agregue anotaciones que no sean cadenas a ext4.h"). • https://git.kernel.org/stable/c/744a56389f7398f286231e062c2e63f0de01bcc6 https://git.kernel.org/stable/c/4378be89ddb7de88d984b67ecfd6191686c42817 https://git.kernel.org/stable/c/be27cd64461c45a6088a91a04eba5cd44e1767ef •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42256 – cifs: Fix server re-repick on subrequest retry
https://notcve.org/view.php?id=CVE-2024-42256
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix server re-repick on subrequest retry When a subrequest is marked for needing retry, netfs will call cifs_prepare_write() which will make cifs repick the server for the op before renegotiating credits; it then calls cifs_issue_write() which invokes smb2_async_writev() - which re-repicks the server. If a different server is then selected, this causes the increment of server->in_flight to happen against one record and the decrement to happen against another, leading to misaccounting. Fix this by just removing the repick code in smb2_async_writev(). As this is only called from netfslib-driven code, cifs_prepare_write() should always have been called first, and so server should never be NULL and the preparatory step is repeated in the event that we do a retry. The problem manifests as a warning looking something like: WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Which may be triggered by a number of different xfstests running against an Azure server in multichannel mode. generic/249 seems the most repeatable, but generic/215, generic/249 and generic/308 may also show it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige la repetición del servidor en el reintento de subrequest Cuando se marca una subrequest para necesitar un reintento, netfs llamará a cifs_prepare_write(), lo que hará que cifs vuelva a seleccionar el servidor para la operación antes de renegociar los créditos; luego llama a cifs_issue_write(), que invoca a smb2_async_writev(), que vuelve a seleccionar el servidor. Si luego se selecciona un servidor diferente, esto hace que el incremento de server->in_flight ocurra en un registro y la disminución en otro, lo que lleva a una contabilidad errónea. • https://git.kernel.org/stable/c/3ee1a1fc39819906f04d6c62c180e760cd3a689d https://git.kernel.org/stable/c/b1d0a566769b6fb3795b5289fc1daf9e0638d97a https://git.kernel.org/stable/c/de40579b903883274fe203865f29d66b168b7236 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42255 – tpm: Use auth only after NULL check in tpm_buf_check_hmac_response()
https://notcve.org/view.php?id=CVE-2024-42255
In the Linux kernel, the following vulnerability has been resolved: tpm: Use auth only after NULL check in tpm_buf_check_hmac_response() Dereference auth after NULL check in tpm_buf_check_hmac_response(). Otherwise, unless tpm2_sessions_init() was called, a call can cause NULL dereference, when TCG_TPM2_HMAC is enabled. [jarkko: adjusted the commit message.] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: use autenticación solo después de la verificación NULL en tpm_buf_check_hmac_response() Desreferenciar la autenticación después de la verificación NULL en tpm_buf_check_hmac_response(). De lo contrario, a menos que se haya llamado a tpm2_sessions_init(), una llamada puede causar una desreferencia NULL, cuando TCG_TPM2_HMAC está habilitado. [jarkko: ajustó el mensaje de confirmación.] • https://git.kernel.org/stable/c/7ca110f2679b7d1f3ac1afc90e6ffbf0af3edf0d https://git.kernel.org/stable/c/b9afbb9a0c734197c59c43610071041044bf1562 https://git.kernel.org/stable/c/7dc357d343f134bf59815ff6098b93503ec8a23b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42254 – io_uring: fix error pbuf checking
https://notcve.org/view.php?id=CVE-2024-42254
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix error pbuf checking Syz reports a problem, which boils down to NULL vs IS_ERR inconsistent error handling in io_alloc_pbuf_ring(). KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__io_remove_buffers+0xac/0x700 io_uring/kbuf.c:341 Call Trace: <TASK> io_put_bl io_uring/kbuf.c:378 [inline] io_destroy_buffers+0x14e/0x490 io_uring/kbuf.c:392 io_ring_ctx_free+0xa00/0x1070 io_uring/io_uring.c:2613 io_ring_exit_work+0x80f/0x8a0 io_uring/io_uring.c:2844 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring: corrige el error pbuf comprobando Syz informa un problema, que se reduce a un manejo inconsistente de errores NULL vs IS_ERR en io_alloc_pbuf_ring(). KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:__io_remove_buffers+0xac/0x700 io_uring/kbuf.c:341 Seguimiento de llamadas: io_put_bl io_uring/kbuf.c:378 línea] io_destroy_buffers+0x14e /0x490 io_uring/kbuf.c:392 io_ring_ctx_free+0xa00/0x1070 io_uring/io_uring.c:2613 io_ring_exit_work+0x80f/0x8a0 io_uring/io_uring.c:2844 Process_one_work kernel/workqueue.c:3231 [en línea] Núcleo 0xa2c/0x1830 /workqueue.c:3312 trabajador_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/ 0x30 arco/x86/entrada/entry_64.S:244 • https://git.kernel.org/stable/c/87585b05757dc70545efb434669708d276125559 https://git.kernel.org/stable/c/68d19af95a353f5e2b021602180b65b303eba99d https://git.kernel.org/stable/c/bcc87d978b834c298bbdd9c52454c5d0a946e97e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42253 – gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
https://notcve.org/view.php?id=CVE-2024-42253
In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: pca953x: corrige la ejecución pca953x_irq_bus_sync_unlock Asegúrese de que se mantenga `i2c_lock' al configurar el bloqueo de interrupción y la máscara en pca953x_irq_bus_sync_unlock() para evitar ejecuciones. El otro sitio de llamada (que no es de sonda) pca953x_gpio_set_multiple() garantiza que el bloqueo se mantenga antes de llamar a pca953x_write_regs(). El problema ocurrió cuando una solicitud corrió contra irq_bus_sync_unlock() aproximadamente una vez por cada mil reinicios en un sistema basado en i.MX8MP. * Caso normal 0-0022: escribir registro AI|3a {03,02,00,00,01} Enclavamiento de entrada P0 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 0 -0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|12 {fc,00,00,00,00} Configuración P3 * Caso de ejecución 0-0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|08 {03,02,00,00,01} *** Registro incorrecto *** 0-0022: escribir registro AI|12 {fc,00,00,00,00} Config P3 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 • https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34 https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2 https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41 https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904 •