Page 240 of 2874 results (0.023 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spmi: mediatek: reparar UAF en la eliminación del dispositivo. Los datos del controlador pmif que contienen los relojes se asignan junto con spmi_controller. Al eliminar el dispositivo, primero se liberará spmi_controller y luego se limpiarán los devres, incluidos los relojes. Esto lleva a UAF porque al poner los relojes se accederá a los relojes en los datos del controlador pmif, que ya están liberados junto con spmi_controller. • https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8 https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ceph: corrige el punto muerto o el código muerto por uso incorrecto de dget() El orden de bloqueo es incorrecto entre denty y su padre, siempre debemos asegurarnos de que el padre obtenga el bloqueo primero. Pero dado que este código muerto nunca se usa y el directorio principal siempre será configurado por quienes llaman, simplemente eliminémoslo. • https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6 https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980 https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3 https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160 https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67 https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a •

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

In the Linux kernel, the following vulnerability has been resolved: inet: fully convert sk->sk_rx_dst to RCU rules syzbot reported various issues around early demux, one being included in this changelog [1] sk->sk_rx_dst is using RCU protection without clearly documenting it. And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv() are not following standard RCU rules. [a] dst_release(dst); [b] sk->sk_rx_dst = NULL; They look wrong because a delete operation of RCU protected pointer is supposed to clear the pointer before the call_rcu()/synchronize_rcu() guarding actual memory freeing. In some cases indeed, dst could be freed before [b] is done. We could cheat by clearing sk_rx_dst before calling dst_release(), but this seems the right time to stick to standard RCU annotations and debugging facilities. [1] BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline] BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792 Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204 CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 dst_check include/net/dst.h:470 [inline] tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792 ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340 ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583 ip_sublist_rcv net/ipv4/ip_input.c:609 [inline] ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644 __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline] __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556 __netif_receive_skb_list net/core/dev.c:5608 [inline] netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699 gro_normal_list net/core/dev.c:5853 [inline] gro_normal_list net/core/dev.c:5849 [inline] napi_complete_done+0x1f1/0x880 net/core/dev.c:6590 virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline] virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557 __napi_poll+0xaf/0x440 net/core/dev.c:7023 napi_poll net/core/dev.c:7090 [inline] net_rx_action+0x801/0xb40 net/core/dev.c:7177 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629 RIP: 0033:0x7f5e972bfd57 Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73 RSP: 002b:00007fff8a413210 EFLAGS: 00000283 RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45 RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45 RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9 R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0 R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019 </TASK> Allocated by task 13: kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] __kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467 kasan_slab_alloc include/linux/kasan.h:259 [inline] slab_post_alloc_hook mm/slab.h:519 [inline] slab_alloc_node mm/slub.c:3234 [inline] slab_alloc mm/slub.c:3242 [inline] kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247 dst_alloc+0x146/0x1f0 net/core/dst.c:92 rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613 ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:234 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet: conversión completa de sk-&gt;sk_rx_dst a reglas de RCU syzbot informó varios problemas relacionados con la demux inicial, uno de los cuales se incluye en este registro de cambios [1] sk-&gt;sk_rx_dst está usando protección de RCU sin claridad documentándolo. Y las siguientes secuencias en tcp_v4_do_rcv()/tcp_v6_do_rcv() no siguen las reglas estándar de RCU. [a] dst_release(dst); [b] sk-&gt;sk_rx_dst = NULL; Se ven incorrectos porque se supone que una operación de eliminación del puntero protegido de RCU borra el puntero antes de que call_rcu()/synchronize_rcu() proteja la liberación de memoria real. De hecho, en algunos casos, dst podría liberarse antes de que se realice [b]. Podríamos hacer trampa borrando sk_rx_dst antes de llamar a dst_release(), pero este parece el momento adecuado para ceñirnos a las anotaciones estándar de RCU y las funciones de depuración • https://git.kernel.org/stable/c/41063e9dd11956f2d285e12e4342e1d232ba0ea2 https://git.kernel.org/stable/c/68c34ce11ef23328692aa35fa6aaafdd75913100 https://git.kernel.org/stable/c/92e6e36ecd16808866ac6172b9491b5097cde449 https://git.kernel.org/stable/c/75a578000ae5e511e5d0e8433c94a14d9c99c412 https://git.kernel.org/stable/c/c3bb4a7e8cbc984e1cdac0fe6af60e880214ed6e https://git.kernel.org/stable/c/f039b43cbaea5e0700980c2f0052da05a70782e0 https://git.kernel.org/stable/c/0249a4b8a554f2eb6a27b62516fa50168584faa4 https://git.kernel.org/stable/c/8f905c0e7354ef261360fb7535ea079b1 •

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

In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: fix global-out-of-bounds issue When eint virtual eint number is greater than gpio number, it maybe produce 'desc[eint_n]' size globle-out-of-bounds issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pinctrl: mediatek: soluciona el problema global fuera de los límites Cuando el número eint virtual eint es mayor que el número gpio, puede producir un tamaño 'desc[eint_n]' globle-out- cuestión de fuera de los límites. • https://git.kernel.org/stable/c/f373298e1bf0c6ea097c0bcc558dc43ad53e421f https://git.kernel.org/stable/c/441d3873664d170982922c5d2fc01fa89d9439ed https://git.kernel.org/stable/c/fb563baa3eb8e7a15f2cff3c2695e2cca0493e69 https://git.kernel.org/stable/c/2d5446da5acecf9c67db1c9d55ae2c3e5de01f8d •

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

In the Linux kernel, the following vulnerability has been resolved: tun: avoid double free in tun_free_netdev Avoid double free in tun_free_netdev() by moving the dev->tstats and tun->security allocs to a new ndo_init routine (tun_net_init()) that will be called by register_netdevice(). ndo_init is paired with the desctructor (tun_free_netdev()), so if there's an error in register_netdevice() the destructor will handle the frees. BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free mm/kasan/common.c:346 [inline] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook mm/slub.c:1749 [inline] slab_free mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 security_tun_dev_free_security+0x4f/0x90 security/security.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/core/dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tun: evita la doble liberación en tun_free_netdev Evita la doble liberación en tun_free_netdev() moviendo las asignaciones dev-&gt;tstats y tun-&gt;security a una nueva rutina ndo_init (tun_net_init()) que será llamado por Register_netdevice(). ndo_init está emparejado con el destructor (tun_free_netdev()), por lo que si hay un error en Register_netdevice() el destructor manejará las liberaciones. ERROR: KASAN: doble liberación o no válido en selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 No contaminado 5.16.0-rc2-syzk #1 Nombre de hardware : Red Hat KVM, seguimiento de llamadas de BIOS: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report. c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free mm/kasan/common.c:346 [en línea] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan .h:235 [en línea] slab_free_hook mm/slub.c:1723 [en línea] slab_free_freelist_hook mm/slub.c:1749 [en línea] slab_free mm/slub.c:3513 [en línea] kfree+0xac/0x2d0 mm/slub.c :4561 selinux_tun_dev_free_security+0x1a/0x20 seguridad/selinux/hooks.c:5605 seguridad_tun_dev_free_security+0x4f/0x90 seguridad/seguridad.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/ núcleo /dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs /ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/ common.c:50 [en línea] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/8eb43d635950e27c29f1e9e49a23b31637f37757 https://git.kernel.org/stable/c/0c0e566f0387490d16f166808c72e9c772027681 https://git.kernel.org/stable/c/a01a4e9f5dc93335c716fa4023b1901956e8c904 https://git.kernel.org/stable/c/3cb5ae77799e8ed6ec3fec0b6b4cd07f01650cc5 https://git.kernel.org/stable/c/158b515f703e75e7d68289bf4d98c664e1d632df •