CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42280 – mISDN: Fix a use after free in hfcmulti_tx()
https://notcve.org/view.php?id=CVE-2024-42280
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp). • https://git.kernel.org/stable/c/af69fb3a8ffa37e986db00ed93099dc44babeef4 https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803 https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3 https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2 https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629 https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80 https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7 https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef7 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42271 – net/iucv: fix use after free in iucv_sock_close()
https://notcve.org/view.php?id=CVE-2024-42271
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. • https://git.kernel.org/stable/c/7d316b9453523498246e9e19a659c423d4c5081e https://git.kernel.org/stable/c/84f40b46787ecb67c7ad08a5bb1376141fa10c01 https://git.kernel.org/stable/c/37652fbef9809411cea55ea5fa1a170e299efcd0 https://git.kernel.org/stable/c/c65f72eec60a34ace031426e04e9aff8e5f04895 https://git.kernel.org/stable/c/ac758e1f663fe9bc64f6b47212a2aa18697524f5 https://git.kernel.org/stable/c/8b424c9e44111c5a76f41c6b741f8d4c4179d876 https://git.kernel.org/stable/c/01437282fd3904810603f3dc98d2cac6b8b6fc84 https://git.kernel.org/stable/c/69620522c48ce8215e5eb55ffbab8cafe •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42265 – protect the fetch of ->fd[fd] in do_dup2() from mispredictions
https://notcve.org/view.php?id=CVE-2024-42265
In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path. • https://git.kernel.org/stable/c/ed42e8ff509d2a61c6642d1825032072dab79f26 https://git.kernel.org/stable/c/41a6c31df77bd8e050136b0a200b537da9e1084a https://git.kernel.org/stable/c/08775b3d6ed117cf4518754ec7300ee42b6a5368 https://git.kernel.org/stable/c/3f480493550b6a23d3a65d095d6569d4a7f56a0f https://git.kernel.org/stable/c/5db999fff545b924b24c9afd368ef5c17279b176 https://git.kernel.org/stable/c/da72e783afd27d9f487836b2e6738146c0edd149 https://git.kernel.org/stable/c/1171ceccabfd596ca370c5d2cbb47d110c3f2fe1 https://git.kernel.org/stable/c/8aa37bde1a7b645816cda8b80df4753ec •
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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42252 – closures: Change BUG_ON() to WARN_ON()
https://notcve.org/view.php?id=CVE-2024-42252
In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cierres: Cambie BUG_ON() a WARN_ON() Si se puede acceder a un BUG_ON() en estado salvaje, no debería ser un BUG_ON() Como referencia, ha aparecido esto una vez en el CI, y necesitaremos más información para depurarlo: 03240 ------------[ cortar aquí ]------------ 03240 ERROR del kernel en lib /cierre.c:21! 03240 ERROR del kernel en lib/closure.c:21! 03240 Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP 03240 Módulos vinculados en: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 No contaminado 6.10.0-rc4-ktest-ga56da69799bd #25570 Nombre del hardware: linux,dummy-virt (DT) 03240 Cola de trabajo: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc: cierre_put+0x224/0x2a0 03240 lr: cierre_put+0x24/ 0x2a0 03240 sp: ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16 : 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: e402d x10: dfff800000000000 x9: ffff6000183e402e 03240 x8: 0000000000000001 x7: 00009fffe7c1bfd3 x6: ffff0000c1f2016b 03240 x5: 0168 x4: ffff6000183e402e x3: ffff800081391954 03240 x2: 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Rastreo de llamadas: 03240 cierre_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c /0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 Process_scheduled_works+0x53c/0xd90 03240 trabajador_thread+0x37 0/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Código: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000 ) 03240 ---[ seguimiento final 0000000000000000 ]--- 03240 Pánico del kernel - no se sincroniza: Ups - ERROR: Excepción fatal 03240 SMP: deteniendo las CPU secundarias 03241 SMP: no se pudieron detener las CPU secundarias 13,15 03241 Desplazamiento del kernel: deshabilitado 03241 CPU características: 0x00,00000003,80000008,4240500b 03241 Límite de memoria: ninguno 03241 ---[ fin del pánico del kernel - no se sincroniza: Ups - ERROR: excepción fatal ]--- 03246 ========= TIEMPO DE ESPERA FALLIDO copygc_torture_no_checksum en 7200 • https://git.kernel.org/stable/c/5d85f2ab79d5918a66539ebf046c099f7448db8d https://git.kernel.org/stable/c/339b84ab6b1d66900c27bd999271cb2ae40ce812 •