Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: eliminar una ubicación errada en la ruta de error drm_gem_shmem_mmap() no posee esta referencia, lo que provoca que el objeto GEM se libere prematuramente y lleve a un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se soluciona el fallo al volver a conectar controladores falsos de CSR Parece que los clones falsos de CSR 5.0 pueden provocar que el notificador de suspensión se registre dos veces, lo que provoca el siguiente pánico del kernel: [ 71.986122] Seguimiento de llamadas: [ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb es: e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] interfaz_sonda_usb+0xe3/0x2b0 [ 71.986171] realmente_sonda+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] __driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_para_cada_unidad+0x8c/0xe0 [ 71.986192] __dispositivo_adjunto+0xb2/0x1e0 [ 71.986195] bus_sondeo_dispositivo+0x92/0xb0 [ 71.986198] dispositivo_agregado+0x422/0x9a0 [ 71.986201] ? usb_probe_device+0x3a/0x110 [ 71.986213] realmente_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_para_cada_unidad+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? subproceso de rescate+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] [ 71.986274] ---[ fin de seguimiento 000000000000000 ]--- [ 71.986284] btusb: la sonda de 2-1.6:1.0 falló con el error -17

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tamaño 4 en la dirección 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobación_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecución_trabajo_tarea+0x164/0x250 ? cancelación_trabajo_tarea+0x30/0x30 obtener_señal+0x1c3/0x2440 ? degradación_bloqueo+0x6e0/0x6e0 ? degradación_bloqueo+0x6e0/0x6e0 ? señales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Pánico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adición de task_work desde io_ring_exit_work() no está sincronizada con la cancelación de todos los elementos de trabajo, por ejemplo, de exec. La ejecución de los dos está ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() está en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current->io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificación NULL aquí, porque la ejecución de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de código y también coloque una explicación en el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: slcan: fix freed work crash La prueba LTP pty03 está provocando un fallo en slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: 0x0 (eventos) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Código: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Seguimiento de llamadas: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Aparentemente, el tx_work de slcan se libera mientras se programa. Mientras que slcan_netdev_close() (lado netdev) llama a flush_work(&sl->tx_work), slcan_close() (lado tty) no lo hace. Entonces, cuando el netdev nunca se configura, pero el tty está lleno de bytes y se lo obliga a activar la escritura, el trabajo se programa, pero nunca se vacía. Por lo tanto, agregue un flush_work() adicional a slcan_close() para asegurarse de que el trabajo se vacía en todas las circunstancias. el commit de correcciones a continuación movió flush_work() de slcan_close() a slcan_netdev_close(). ¿Cuál fue la razón detrás de esto? ¿Quizás podamos eliminar el que está en slcan_netdev_close()? Veo el mismo patrón en can327. Entonces, tal vez necesite la misma corrección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Corregir ejecución en la variable per-CQ napi work_done Después de llamar a napi_complete_done(), el bit NAPIF_STATE_SCHED puede borrarse, y otra CPU puede iniciar el hilo napi y acceder a la variable per-CQ, cq->work_done. Si el otro hilo (por ejemplo, desde busy_poll) lo establece en un valor >= budget, este hilo seguirá ejecutándose cuando debería detenerse, y provocará corrupción de memoria y pánico. Para solucionar este problema, guarde la variable per-CQ work_done en una variable local antes de napi_complete_done(), para que no se corrompa por un posible hilo concurrente después de napi_complete_done(). Además, agregue un bit de bandera para anunciar al firmware NIC: la ejecución de la variable NAPI work_done está fija, por lo que el controlador puede soportar de forma fiable funciones como busy_poll.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: fix gup_pud_range() for dax Para dax pud, pud_huge() devuelve true en x86. Por lo tanto, la función funciona siempre que hugetlb esté configurado. Sin embargo, dax no depende de hugetlb. el commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") corrigió los PMD enormes respaldados por devmap, pero omitió los PUD enormes respaldados por devmap. Corrija esto también. Esto corrige el siguiente pánico del kernel: error de protección general, probablemente para la dirección no canónica 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > ---[ fin del seguimiento 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Pánico del núcleo: no se sincroniza: Excepción fatal Desplazamiento del núcleo: deshabilitado

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: v4l2-dv-timings.c: se corrigen comprobaciones de cordura de borrado demasiado estrictas Se añadieron comprobaciones de cordura para verificar los campos de borrado de v4l2_bt_timings para evitar desbordamientos de enteros cuando el espacio de usuario pasa valores extraños. Pero eso suponía que el espacio de usuario rellenaría correctamente los valores de front porch, back porch y sync, pero a veces todo lo que sabes es el borrado total, que luego se asigna a solo uno de estos campos. Y eso puede fallar con estas comprobaciones. Así que, en su lugar, establece un máximo para el borrado horizontal y vertical total y comprueba que cada campo permanezca por debajo de eso. Eso sigue siendo suficiente para evitar desbordamientos de enteros, pero también permite más flexibilidad en cómo el espacio de usuario rellena estos campos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: corregir posible use after free en memcg_write_event_control() memcg_write_event_control() accede a dentry->d_name del fd de control especificado para enrutar la llamada de escritura. Como no se puede cambiar el nombre de un archivo de interfaz de cgroup, es seguro acceder a d_name siempre que el archivo especificado sea un archivo cgroup normal. Además, como estos archivos de interfaz de cgroup no se pueden eliminar antes del directorio, también es seguro acceder al padre. Antes de 347c4a874710 ("memcg: eliminar cgroup_event->cft"), había una llamada a __file_cft() que verificaba que el archivo especificado es un archivo cgroupfs normal antes de futuros accesos. El puntero cftype devuelto desde __file_cft() ya no era necesario y el commit eliminó inadvertidamente la verificación del tipo de archivo, lo que permitió que cualquier archivo se deslizara. Con las invariantes rotas, los accesos a d_name y a los padres ahora pueden competir contra los cambios de nombre y las eliminaciones de archivos arbitrarios y causar use-after-free. Corrija el error resucitando la comprobación del tipo de archivo en __file_cft(). Ahora que cgroupfs está implementado a través de kernfs, la comprobación de las operaciones de archivo debe pasar por una capa de indirección. En su lugar, verifiquemos el tipo de superbloque y dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: Corregir oops debido a ejecución con cookie_lru y use_cookie Si una cookie caduca desde la LRU y el indicador LRU_DISCARD está configurado, pero la máquina de estado aún no se ha ejecutado, es posible que otro hilo pueda llamar a fscache_use_cookie y comenzar a usarlo. Cuando finalmente se ejecuta cookie_worker, verá el indicador LRU_DISCARD configurado, hará la transición de cookie->state a LRU_DISCARDING, que luego retirará la cookie. Una vez que se retira la cookie, se elimina el objeto, se producirán los siguientes oops porque el objeto asociado con la cookie ahora es NULL. Corrija los oops borrando el bit LRU_DISCARD si otro hilo usa la cookie antes de que se ejecute cookie_worker. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Contaminado: GE 6.0.0-5.dneg.x86_64 #1 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/08/2022 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Seguimiento de llamadas: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 hilo+0xd6/0x100

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corregir el use after free durante la recuperación de la GPU [Por qué] [ 754.862560] refcount_t: desbordamiento; use after free. [ 754.862898] Seguimiento de llamadas: [ 754.862903] [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [Cómo] Es posible que fw_fence no se inicialice, verifique si dma_fence_init se realiza antes de la liberación del trabajo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: Reparar sring NULL después de la migración en vivo Se configura un NAPI para cada sring de red para sondear los datos al kernel El sring con el host de origen se destruye antes de la migración en vivo y se configura el nuevo sring con el host de destino después de la migración en vivo. El NAPI para el sring antiguo no se elimina hasta que se configura el nuevo sring con el host de destino después de la migración. Con busy_poll/busy_read habilitado, el NAPI se puede sondear antes de que se elimine cuando se reanuda la VM. ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] Seguimiento de llamadas PTI de SMP: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 evento_hist_trigger+0x14a/0x260 finalizar_cambio_tarea+0x71/0x230 __schedule+0x256/0x890 recalc_sigping+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 reserva_bloqueo_buffer_anillo+0x123/0x3d0 llamada_activadores_evento+0x87/0xb0 confirmación_buffer_evento_trace+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ fin del seguimiento f8601785b354351c ]--- la interfaz de xen debe eliminar las NAPI de los antiguos srings antes de la migración en vivo, ya que los srings de enlace se destruyen. Hay una pequeña ventana entre los srings que se establecen en NULL y los NAPI que se deshabilitan. Es seguro ya que los subprocesos NAPI todavía están congelados en ese momento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Obtener user_ns de in_skb en unix_diag_get_exact(). Wei Chen informó una desreferencia NULL en sk_user_ns() [0][1], y Paolo diagnosticó la causa raíz: en unix_diag_get_exact(), el skb recién asignado no tiene sk. [2] Debemos obtener el user_ns de NETLINK_CB(in_skb).sk y pasarlo a sk_diag_fill(). [0]: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000270 #PF: acceso de lectura del supervisor en modo núcleo #PF: error_code(0x0000) - página no presente PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 No contaminado 6.1.0-rc5-next-20221118 #2 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_user_ns include/net/sock.h:920 [en línea] RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [en línea] RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170 Código: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: unix_diag_get_exact net/unix/diag.c:285 [en línea] unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317 __sock_diag_cmd net/core/sock_diag.c:235 [en línea] sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [en línea] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0x38f/0x500 net/socket.c:2476 ___sys_sendmsg net/socket.c:2530 [en línea] __sys_sendmsg+0x197/0x230 net/socket.c:2559 __do_sys_sendmsg net/socket.c:2568 [en línea] __se_sys_sendmsg net/socket.c:2566 [en línea] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4697f9 Código: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 000000000000000 RSI: 00000000200001c0 RDI: 000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 Módulos vinculados en: CR2: 0000000000000270 [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/