Page 239 of 2802 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: abort in rename_exchange if we fail to insert the second ref Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: abortar en rename_exchange si no logramos insertar la segunda referencia. • https://git.kernel.org/stable/c/0df50d47d17401f9f140dfbe752a65e5d72f9932 https://git.kernel.org/stable/c/ff8de2cec65a8c8521faade12a31b39c80e49f5b https://git.kernel.org/stable/c/dc09ef3562726cd520c8338c1640872a60187af5 •

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

In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Teardown PV features on boot CPU as well Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor and when we restore from hibernation we must properly teardown all these features to make sure hypervisor doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place anything there). For secondary CPUs the job is already done by kvm_cpu_down_prepare(), register syscore ops to do the same for boot CPU. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kvm: Desmontaje de funciones PV también en la CPU de arranque Varias funciones PV (Async PF, PV EOI, tiempo de robo) funcionan a través de la memoria compartida con el hipervisor y cuando restauramos desde la hibernación Debemos eliminar adecuadamente todas estas características para asegurarnos de que el hipervisor no escriba en ubicaciones obsoletas después de saltar al kernel previamente hibernado (que puede intentar colocar cualquier cosa allí). Para las CPU secundarias, el trabajo ya lo realiza kvm_cpu_down_prepare(), registre syscore ops para hacer lo mismo para la CPU de arranque. • https://git.kernel.org/stable/c/7620a669111b52f224d006dea9e1e688e2d62c54 https://git.kernel.org/stable/c/38b858da1c58ad46519a257764e059e663b59ff2 https://git.kernel.org/stable/c/d1629b5b925de9b27979e929dae7fcb766daf6b6 https://git.kernel.org/stable/c/8b79feffeca28c5459458fe78676b081e87c93a4 •

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

In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Disable kvmclock on all CPUs on shutdown Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU. We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate. Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating the location so for the short while after write and while CPU is still alive, the clock remains usable and correct so we don't need to switch to some other clocksource. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/kvm: deshabilite kvmclock en todas las CPU al apagar Actualmente, deshabilitamos kvmclock desde el enlace machine_shutdown() y esto solo sucede para la CPU de arranque. Necesitamos deshabilitarlo para todas las CPU para protegernos contra la corrupción de la memoria, por ejemplo, al restaurar desde la hibernación. Tenga en cuenta que escribir '0' en kvmclock MSR no borra la ubicación de la memoria, solo evita que el hipervisor actualice la ubicación, por lo que durante un breve período después de la escritura y mientras la CPU aún está activa, el reloj permanece utilizable y correcto, por lo que no lo necesitamos. para cambiar a alguna otra fuente de reloj. • https://git.kernel.org/stable/c/9084fe1b3572664ad276f427dce575f580c9799a https://git.kernel.org/stable/c/3b0becf8b1ecf642a9edaf4c9628ffc641e490d6 https://git.kernel.org/stable/c/1df2dc09926f61319116c80ee85701df33577d70 https://git.kernel.org/stable/c/c02027b5742b5aa804ef08a4a9db433295533046 •

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

In the Linux kernel, the following vulnerability has been resolved: llc: call sock_orphan() at release time syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket. In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling proto_ops::release()") Eric Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 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> Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: llame a sock_orphan() en el momento del lanzamiento syzbot informó un rastro interesante [1] causado por un puntero sk-&gt;sk_wq obsoleto en un socket llc cerrado. En El commit ff7b11aa481f ("net: socket: set sock-&gt;sk to NULL after call proto_ops::release()") Eric Biggers insinuó que a algunos protocolos les falta un sock_orphan(), necesitamos realizar una auditoría completa. En net-next, planeo borrar sock-&gt;sk de sock_orphan() y modificar el parche de Eric para agregar una advertencia. [1] ERROR: KASAN: slab-use-after-free en list_empty include/linux/list.h:373 [en línea] ERROR: KASAN: slab-use-after-free en waitqueue_active include/linux/wait.h:127 [en línea] ERROR: KASAN: slab-use-after-free en sock_def_write_space_wfree net/core/sock.c:3384 [en línea] ERROR: KASAN: slab-use-after-free en sock_wfree+0x9a8/0x9d0 net/core/sock .c:2468 Lectura del tamaño 8 en la dirección ffff88802f4fc880 por tarea ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack .c:106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/ list.h:373 [en línea] waitqueue_active include/linux/wait.h:127 [en línea] sock_def_write_space_wfree net/core/sock.c:3384 [en línea] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+ 0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [en línea] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/ intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq controladores/net/ethernet/intel/e1000/e1000_main.c:3860 [en línea] e1000_clean+0x4a1/0x26e0 controladores/net/ethernet/intel/e1000/e1000_main.c:3801 __ napi_poll. constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [en línea] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/ softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [en línea] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 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 Asignado por tarea 5167: kasan_save_stack+0x33/0x50 mm/ kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [en línea] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc incluir /linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3813 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/ fs.h:3019 [en línea] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net /socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [en línea] __sys_socket_create net/socket.c:1659 [en línea] __sys_socket+0x14c/0x260 net/socket.c :1706 __do_sys_socket net/socket.c:1720 [en línea] __se_sys_socket net/socket.c:1718 [en línea] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Liberado por la tarea 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/ common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux /kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea ---truncado--- • https://git.kernel.org/stable/c/43815482370c510c569fd18edb57afcb0fa8cab6 https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7 https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812 https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791 •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige la desreferencia del puntero nulo en pgtable_cache_add kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. A possible null-pointer dereference was found in pgtable_cache_add in the Linux kernel. • https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611 https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7 https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1 https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532 https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74 https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced • CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference •