Page 138 of 3082 results (0.007 seconds)

CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: serialize hash resizes and cleanups Syzbot was able to trigger the following warning [1] No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and: for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done It would take more than 5 minutes for net_namespace structures to be cleaned up. This is because nf_ct_iterate_cleanup() has to restart everytime a resize happened. By adding a mutex, we can serialize hash resizes and cleanups and also make get_next_corpse() faster by skipping over empty buckets. Even without resizes in the picture, this patch considerably speeds up network namespace dismantles. [1] INFO: task syz-executor.0:8312 can't die for more than 144 seconds. task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006 Call Trace: context_switch kernel/sched/core.c:4955 [inline] __schedule+0x940/0x26f0 kernel/sched/core.c:6236 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 local_bh_enable include/linux/bottom_half.h:32 [inline] get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline] nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 setup_net+0x639/0xa30 net/core/net_namespace.c:349 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksys_unshare+0x445/0x920 kernel/fork.c:3128 __do_sys_unshare kernel/fork.c:3202 [inline] __se_sys_unshare kernel/fork.c:3200 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000 Showing all locks held in the system: 1 lock held by khungtaskd/27: #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446 2 locks held by kworker/u4:2/153: #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 1 lock held by systemd-udevd/2970: 1 lock held by in:imklog/6258: #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990 3 locks held by kworker/1:6/8158: 1 lock held by syz-executor.0/8312: 2 locks held by kworker/u4:13/9320: 1 lock held by ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: conntrack: serializar cambios de tamaño y limpiezas de hash. Syzbot pudo activar la siguiente advertencia [1] Syzbot aún no encontró ninguna reproducción, pero pude desencadenar un problema similar al tener 2 scripts ejecutándose en paralelo, cambiando los tamaños de hash de conntrack y: para j en `seq 1 1000`; dejar de compartir -n /bin/true >/dev/null ; done Se necesitarían más de 5 minutos para limpiar las estructuras net_namespace. Esto se debe a que nf_ct_iterate_cleanup() tiene que reiniciarse cada vez que ocurre un cambio de tamaño. Al agregar un mutex, podemos serializar los cambios de tamaño y las limpiezas de hash y también hacer que get_next_corpse() sea más rápido omitiendo los depósitos vacíos. Incluso sin cambios de tamaño en la imagen, este parche acelera considerablemente el desmantelamiento del espacio de nombres de la red. [1] INFORMACIÓN: la tarea syz-executor.0:8312 no puede morir durante más de 144 segundos. tarea:syz-executor.0 estado:R ejecutando pila de tareas:25672 pid: 8312 ppid: 6573 banderas:0x00004006 Seguimiento de llamadas: context_switch kernel/sched/core.c:4955 [en línea] __schedule+0x940/0x26f0 kernel/sched/core .c:6236 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 local_bh_enable include/ Linux /bottom_half.h:32 [en línea] get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [en línea] nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/ nf_conntrack_core.c:2469 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 setup_net+0x639/0xa30 net/core/net_namespace.c:349 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy .c:110 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksys_unshare+0x445/0x920 kernel/fork.c:3128 __do_sys_unshare kernel/fork.c:3202 [en línea] __se_sys_unshare kernel/fork.c:3200 [en línea] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae : 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000 Mostrando todos los bloqueos retenidos en el sistema: 1 bloqueo retenido por khungtaskd/27: #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, : debug_show_all_locks+0x53 /0x260 kernel/locking/lockdep.c:6446 2 bloqueos retenidos por kworker/u4:2/153: #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: arch_atomic64_set arch /x86/include/asm/atomic64_64.h:34 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: arch_atomic_long_set include/linux/atomic/atomic-long .h:41 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [en línea] # 0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: set_work_data kernel/workqueue.c:634 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+. }-{0:0}, en: set_work_pool_and_clear_pending kernel/workqueue.c:661 [en línea] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, en: Process_one_work+0x896/ 0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, en: Process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 1 bloqueo retenido por systemd-udevd/2970: 1 bloqueo retenido por in:imklog/6258: #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, en: __fdget_pos+0xe9/0x100 ---truncado--- A vulnerability was found in the Linux kernel’s netfilter and conntrack module, occurring during the resizing and cleanup of hash tables used for connection tracking. • https://git.kernel.org/stable/c/e2d192301a0df8160d1555b66ae8611e8050e424 https://git.kernel.org/stable/c/7ea6f5848281182ce0cff6cafdcf3fbdeb8ca7e1 https://git.kernel.org/stable/c/e9edc188fc76499b0b9bd60364084037f6d03773 https://access.redhat.com/security/cve/CVE-2021-47408 https://bugzilla.redhat.com/show_bug.cgi?id=2282328 • CWE-667: Improper Locking •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Handle SRCU initialization failure during page track init Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller. [Move the call towards the beginning of kvm_arch_init_vm. - Paolo] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Manejar el error de inicialización de SRCU durante el inicio del seguimiento de la página. Verifique el retorno de init_srcu_struct(), que puede fallar debido a OOM, al inicializar el mecanismo de seguimiento de la página. La falta de verificación conduce a un puntero NULL deref encontrado por un syzkaller modificado. [Mueva la llamada hacia el principio de kvm_arch_init_vm. • https://git.kernel.org/stable/c/deb2949417677649e2413266d7ce8c2ff73952b4 https://git.kernel.org/stable/c/4664318f73e496cd22c71b10888e75434a123e23 https://git.kernel.org/stable/c/eb7511bf9182292ef1df1082d23039e856d1ddfb •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: free raw_report buffers in usbhid_stop Free the unsent raw_report buffers when the device is removed. Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: usbhid: buffers raw_report libres en usbhid_stop. Libera los buffers raw_report no enviados cuando se elimina el dispositivo. Corrige una pérdida de memoria informada por syzbot en: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47 • https://git.kernel.org/stable/c/7ce4e49146612261265671b1d30d117139021030 https://git.kernel.org/stable/c/efc5c8d29256955cc90d8d570849b2d6121ed09f https://git.kernel.org/stable/c/c3156fea4d8a0e643625dff69a0421e872d1fdae https://git.kernel.org/stable/c/764ac04de056801dfe52a716da63f6e7018e7f3b https://git.kernel.org/stable/c/965147067fa1bedff3ae1f07ce3f89f1a14d2df3 https://git.kernel.org/stable/c/f7ac4d24e1610b92689946fa88177673f1e88a3f https://git.kernel.org/stable/c/2b704864c92dcec2b295f276fcfbfb81d9831f81 https://git.kernel.org/stable/c/f7744fa16b96da57187dc8e5634152d3b •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: HID: betop: fix slab-out-of-bounds Write in betop_probe Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption. So this patch checks hid_device's input is non empty before it's been used. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: betop: corrige escritura slab-out-of-bounds en betop_probe. Syzbot informó un error de escritura slab-out-of-bounds en el controlador hid-betopff. El problema es que el controlador supone que el dispositivo debe tener un informe de entrada, pero algunos dispositivos maliciosos violan esta suposición. Entonces, este parche verifica que la entrada de hid_device no esté vacía antes de usarse. • https://git.kernel.org/stable/c/a4faa7153b87fbcfe4be15f4278676f79ca6e019 https://git.kernel.org/stable/c/6fc4476dda58f6c00097c7ddec3b772513f57525 https://git.kernel.org/stable/c/1c83c38dec83d57bc18d0c01d82c413d3b34ccb9 https://git.kernel.org/stable/c/bb8b72374db69afa25a5b65cf1c092860c6fe914 https://git.kernel.org/stable/c/fe9bb925e7096509711660d39c0493a1546e9550 https://git.kernel.org/stable/c/dedfc35a2de2bae9fa3da8210a05bfd515f83fee https://git.kernel.org/stable/c/708107b80aa616976d1c5fa60ac0c1390749db5e https://git.kernel.org/stable/c/1e4ce418b1cb1a810256b5fb3fd33d22d •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests The FSM can run in a circle allowing rdma_resolve_ip() to be called twice on the same id_priv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): for #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. handler still running ..] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the req_list rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // process_one_req() self removes it spin_lock_bh(&lock); cancel_delayed_work(&req->work); if (!list_empty(&req->list)) == true ! rdma_addr_cancel() returns after process_on_req #1 is done kfree(id_priv) process_one_req(): for #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! • https://git.kernel.org/stable/c/e51060f08a61965c4dd91516d82fe90617152590 https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589 https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808 •