CVE-2021-47082 – tun: avoid double free in tun_free_netdev
https://notcve.org/view.php?id=CVE-2021-47082
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->tstats y tun->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 •
CVE-2021-47086 – phonet/pep: refuse to enable an unbound pipe
https://notcve.org/view.php?id=CVE-2021-47086
In the Linux kernel, the following vulnerability has been resolved: phonet/pep: refuse to enable an unbound pipe This ioctl() implicitly assumed that the socket was already bound to a valid local socket name, i.e. Phonet object. If the socket was not bound, two separate problems would occur: 1) We'd send an pipe enablement request with an invalid source object. 2) Later socket calls could BUG on the socket unexpectedly being connected yet not bound to a valid object. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phonet/pep: se niega a habilitar una tubería independiente. Este ioctl() supone implícitamente que el socket ya estaba vinculado a un nombre de socket local válido, es decir, objeto Phonet. • https://git.kernel.org/stable/c/0bbdd62ce9d44f3a22059b3d20a0df977d9f6d59 https://git.kernel.org/stable/c/b10c7d745615a092a50c2e03ce70446d2bec2aca https://git.kernel.org/stable/c/311601f114859d586d5ef8833d60d3aa23282161 https://git.kernel.org/stable/c/982b6ba1ce626ef87e5c29f26f2401897554f235 https://git.kernel.org/stable/c/48c76fc53582e7f13c1e0b11c916e503256c4d0b https://git.kernel.org/stable/c/52ad5da8e316fa11e3a50b3f089aa63e4089bf52 https://git.kernel.org/stable/c/53ccdc73eedaf0e922c45b569b797d2796fbaafa https://git.kernel.org/stable/c/75a2f31520095600f650597c0ac41f48b •
CVE-2024-26622 – tomoyo: fix UAF write bug in tomoyo_write_control()
https://notcve.org/view.php?id=CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tomoyo: corrige el error de escritura UAF en tomoyo_write_control() Dado que tomoyo_write_control() actualiza head->write_buf cuando se solicita write() de líneas largas, necesitamos recuperar head->write_buf después head->io_sem se mantiene. De lo contrario, las solicitudes de escritura () simultáneas pueden causar problemas de use-after-free-write y de doble liberación. • https://git.kernel.org/stable/c/bd03a3e4c9a9df0c6b007045fa7fc8889111a478 https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824 https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711 https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVE-2023-52582 – netfs: Only call folio_start_fscache() one time for each folio
https://notcve.org/view.php?id=CVE-2023-52582
In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cut here ]------------ kernel BUG at include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50 • https://git.kernel.org/stable/c/3d3c95046742e4eebaa4b891b0b01cbbed94ebbd https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412 •
CVE-2023-52581 – netfilter: nf_tables: fix memleak when more than 255 elements expired
https://notcve.org/view.php?id=CVE-2023-52581
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak when more than 255 elements expired When more than 255 elements expired we're supposed to switch to a new gc container structure. This never happens: u8 type will wrap before reaching the boundary and nft_trans_gc_space() always returns true. This means we recycle the initial gc container structure and lose track of the elements that came before. While at it, don't deref 'gc' after we've passed it to call_rcu. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige memleak cuando caducan más de 255 elementos Cuando caducan más de 255 elementos, se supone que debemos cambiar a una nueva estructura de contenedor gc. Esto nunca sucede: el tipo u8 se ajustará antes de alcanzar el límite y nft_trans_gc_space() siempre devuelve verdadero. Esto significa que reciclamos la estructura inicial del contenedor gc y perdemos la pista de los elementos anteriores. Mientras lo hace, no elimine 'gc' después de que lo hayamos pasado a call_rcu. • https://git.kernel.org/stable/c/5f68718b34a531a556f2f50300ead2862278da26 https://git.kernel.org/stable/c/0624f190b5742a1527cd938295caa8dc5281d4cd https://git.kernel.org/stable/c/4aea243b6853d06c1d160a9955b759189aa02b14 https://git.kernel.org/stable/c/cf5000a7787cbc10341091d37245a42c119d26c5 https://git.kernel.org/stable/c/7cf055b43756b10aa2b851c927c940f5ed652125 https://git.kernel.org/stable/c/a995a68e8a3b48533e47c856865d109a1f1a9d01 https://git.kernel.org/stable/c/09c85f2d21ab6b5acba31a037985b13e8e6565b8 https://git.kernel.org/stable/c/ef99506eaf1dc31feff1adfcfd68bc553 • CWE-401: Missing Release of Memory after Effective Lifetime •