CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26682 – wifi: mac80211: improve CSA/ECSA connection refusal
https://notcve.org/view.php?id=CVE-2024-26682
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: improve CSA/ECSA connection refusal As mentioned in the previous commit, we pretty quickly found that some APs have ECSA elements stuck in their probe response, so using that to not attempt to connect while CSA is happening we never connect to such an AP. Improve this situation by checking more carefully and ignoring the ECSA if cfg80211 has previously detected the ECSA element being stuck in the probe response. Additionally, allow connecting to an AP that's switching to a channel it's already using, unless it's using quiet mode. In this case, we may just have to adjust bandwidth later. If it's actually switching channels, it's better not to try to connect in the middle of that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: mac80211: improve CSA/ECSA connection refusal". Como se mencionó en el commit anterior, descubrimos rápidamente que algunos AP tienen elementos ECSA atascados en su respuesta de sondeo, por lo que no se pueden usar si intentamos conectarnos mientras se realiza CSA, nunca nos conectaremos a dicho AP. • https://git.kernel.org/stable/c/c09c4f31998bac6d73508e38812518aceb069b68 https://git.kernel.org/stable/c/ea88bde8e3fefbe4268f6991375dd629895a090a https://git.kernel.org/stable/c/35e2385dbe787936c793d70755a5177d267a40aa •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26681 – netdevsim: avoid potential loop in nsim_dev_trap_report_work()
https://notcve.org/view.php?id=CVE-2024-26681
In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: evita un posible bucle en nsim_dev_trap_report_work() Muchos informes de syzbot incluyen el siguiente seguimiento [1] Si nsim_dev_trap_report_work() no puede capturar el mutex, debería rearmarse al menos un santiamén después . [1] Envío de NMI desde la CPU 1 a las CPU 0: seguimiento de NMI para la CPU 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [ en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Código: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: ffffbfff258af1e RBX: ffffbfff258af1f RCX: ffffffff8168eda3 RDX: ffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: ffffbfff258af1e R08: 00000000000000000 R09: f ffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000 000000000000(0000) GS: ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR 4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 00000 00000000400 Seguimiento de llamadas: < NMI> instrument_atomic_read include/linux/instrumented.h:68 [en línea] atomic_read include/linux/atomic/atomic-instrumented.h:32 [en línea] queued_spin_is_locked include/asm-generic/qspinlock.h: 57 [en línea] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [en línea] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [en línea] _raw_spin_unlock_irqrestore +0x22/0x70 núcleo /locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [en línea] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/ workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [en línea] Schedule_delayed_work include/linux/workqueue.h :677 [en línea] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 Process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x1290 núcleo /workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 • https://git.kernel.org/stable/c/012ec02ae4410207f796a9b280a60b80b6cc790a https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46 https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26680 – net: atlantic: Fix DMA mapping for PTP hwts ring
https://notcve.org/view.php?id=CVE-2024-26680
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? • https://git.kernel.org/stable/c/94ad94558b0fbf18dd6fb0987540af1693157556 https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12 https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56 https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1 https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26679 – inet: read sk->sk_family once in inet_recv_error()
https://notcve.org/view.php?id=CVE-2024-26679
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: lee sk->sk_family una vez en inet_recv_error() se llama a inet_recv_error() sin mantener el bloqueo del socket. El socket IPv6 podría mutar a IPv4 con la opción de socket IPV6_ADDRFORM y generar una advertencia de KCSAN. • https://git.kernel.org/stable/c/f4713a3dfad045d46afcb9c2a7d0bba288920ed4 https://git.kernel.org/stable/c/433337f9c00cac447d020922f59237273f5d92be https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40 https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41 https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299 https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26678 – x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section
https://notcve.org/view.php?id=CVE-2024-26678
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y) This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image. Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps. So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/efistub: use archivo 1:1: mapeo de memoria para PE/COFF sección .compat La sección .compat es una sección PE ficticia que contiene la dirección del punto de entrada de 32 bits de la imagen del kernel de 64 bits si se puede iniciar desde firmware de 32 bits (es decir, CONFIG_EFI_MIXED=y) Esta sección tiene solo 8 bytes de tamaño y solo se hace referencia a ella desde el cargador, por lo que se coloca al final de la memoria. vista de la imagen, para evitar la necesidad de rellenarla a 4k, lo cual es necesario para las secciones que aparecen en el medio de la imagen. Desafortunadamente, esto viola la especificación PE/COFF, e incluso si la mayoría de los cargadores EFI funcionan correctamente (incluida la implementación de referencia de Tianocore), existen cargadores PE que rechazan dichas imágenes, basándose en que tanto las vistas de archivo como de memoria del contenido del archivo deben ser descritos por los encabezados de las secciones de manera monótonamente creciente sin dejar espacios en blanco. Así que reorganice las secciones para evitar este problema. Esto da como resultado una ligera sobrecarga de relleno (< 4k) que se puede evitar si se desea deshabilitando CONFIG_EFI_MIXED (que solo es necesario en casos excepcionales en estos días) • https://git.kernel.org/stable/c/3e3eabe26dc88692d34cf76ca0e0dd331481cc15 https://git.kernel.org/stable/c/4adeeff8c12321cd453412a659c3c0eeb9bb2397 https://git.kernel.org/stable/c/1ad55cecf22f05f1c884adf63cc09d3c3e609ebf https://git.kernel.org/stable/c/d327e961573fc335af0ae8a160302205327e1f4e https://git.kernel.org/stable/c/0a962f2fbaa976af9eed21d0306370cded485787 •