CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-46955 – openvswitch: fix stack OOB read while fragmenting IPv4 packets
https://notcve.org/view.php?id=CVE-2021-46955
In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while fragmenting IPv4 packets running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: corrige la lectura OOB de la pila al fragmentar paquetes IPv4 al ejecutar openvswitch en kernels creados con KASAN, es posible ver el siguiente símbolo al probar la fragmentación de paquetes IPv4: ERROR: KASAN: stack- fuera de los límites en ip_do_fragment+0x1b03/0x1f60 Lectura de tamaño 1 en la dirección ffff888112fc713c por task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Nombre de hardware: Red Hat KVM, BIOS 1.11 .1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_do it.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/ 0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sy s_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7f957079db07 Código: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RB X: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 00000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 00000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 La dirección del error pertenece a la página: página:00000000af2a1d93 refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn: 0x112fc7 banderas: 0x17ffffc0000000() sin formato: 0017ffffc0000000 0000000000000000 muerto000000000122 00000000000000000 sin formato: 0000000000000000 000000000000 0000 00000000ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado addr ffff888112fc713c está ubicado en la pila del controlador de tareas 2/1367 en el desplazamiento 180 en el framework: ovs_fragment+0x0/0x840 [ openvswitch] este framework tiene 2 objetos: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Estado de la memoria alrededor de la dirección del error: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88811 2fc7080 : 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 para paquetes IPv4, ovs_fragment() utiliza una estructura temporal dst_entry. Luego, en el siguiente gráfico de llamadas: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() el puntero a struct dst_entry se usa como puntero a struct rtable: esto convierte el acceso a miembros de estructura como rt_mtu_locked en una lectura OOB en la pila. • https://git.kernel.org/stable/c/119bbaa6795a4f4aed46994cc7d9ab01989c87e3 https://git.kernel.org/stable/c/d543907a4730400f5c5b684c57cb5bbbfd6136ab https://git.kernel.org/stable/c/8387fbac8e18e26a60559adc63e0b7067303b0a4 https://git.kernel.org/stable/c/d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 https://git.kernel.org/stable/c/df9ece1148e2ec242871623dedb004f7a1387125 https://git.kernel.org/stable/c/b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f https://git.kernel.org/stable/c/23e17ec1a5eb53fe39cc34fa5592686d5acd0dac https://git.kernel.org/stable/c/5a52fa8ad45b5a593ed416adf32653863 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2021-46939 – tracing: Restructure trace_clock_global() to never block
https://notcve.org/view.php?id=CVE-2021-46939
In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? • https://git.kernel.org/stable/c/14131f2f98ac350ee9e73faed916d2238a8b6a0d https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4 https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545 https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44 https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534 https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f95006 • CWE-662: Improper Synchronization CWE-833: Deadlock •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46938 – dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails
https://notcve.org/view.php?id=CVE-2021-46938
In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm rq: corrige la liberación doble de blk_mq_tag_set en dev y se elimina después de que falla la carga de la tabla Al cargar una tabla de mapeador de dispositivos para un dispositivo mapeado basado en solicitudes y la asignación/inicialización de blk_mq_tag_set Si el dispositivo falla, la siguiente eliminación del dispositivo provocará una doble liberación. Por ejemplo, (dmesg): mapeador de dispositivos: núcleo: no se puede inicializar la cola para el dispositivo asignado dm-mq basado en solicitudes mapeador de dispositivos: ioctl: no se puede configurar la cola de dispositivos para una nueva tabla. • https://git.kernel.org/stable/c/1c357a1e86a4227a6b6059f2de118ae47659cebc https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9 https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3 https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67 https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9 https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80 • CWE-415: Double Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2020-36777 – media: dvbdev: Fix memory leak in dvb_media_device_free()
https://notcve.org/view.php?id=CVE-2020-36777
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in dvb_media_device_free() dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before setting it to NULL, as documented in include/media/media-device.h: "The media_entity instance itself must be freed explicitly by the driver if required." En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvbdev: corrige la pérdida de memoria en dvb_media_device_free() dvb_media_device_free() está perdiendo memoria. Libere `dvbdev->adapter->conn` antes de configurarlo en NULL, como se documenta en include/media/media-device.h: "La instancia media_entity debe ser liberada explícitamente por el controlador si es necesario". A flaw was found in the Linux kernel. • https://git.kernel.org/stable/c/0230d60e4661d9ced6fb0b9a30f182ebdafbba7a https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275 https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98 https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749 https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066 https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46936 – net: fix use-after-free in tw_timer_handler
https://notcve.org/view.php?id=CVE-2021-46936
In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige use-after-free en tw_timer_handler Se encontró un problema de pánico en el mundo real como se muestra a continuación en Linux 5.4. ERROR: no se puede manejar el error de página para la dirección: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Seguimiento de llamadas: call_timer_fn+0x2b/ 0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/ 0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 Este problema también se informó desde 2017 en el hilo [1], desafortunadamente, el problema aún se puede reproducir después de corregir DCCP. ipv4_mib_exit_net se llama antes de tcp_sk_exit_batch cuando se destruye un espacio de nombres de red, ya que tcp_sk_ops está registrado antes de ipv4_mib_ops, lo que significa que tcp_sk_ops está al frente de ipv4_mib_ops en la lista de pernet_list. • https://git.kernel.org/stable/c/61a7e26028b94805fd686a6dc9dbd9941f8f19b0 https://git.kernel.org/stable/c/15579e1301f856ad9385d720c9267c11032a5022 https://git.kernel.org/stable/c/e73164e89d1be561228a4534e1091369ee4ba41a https://git.kernel.org/stable/c/5c2fe20ad37ff56070ae0acb34152333976929b4 https://git.kernel.org/stable/c/a8e1944b44f94f5c5f530e434c5eaee787254566 https://git.kernel.org/stable/c/fe5838c22b986c1190f1dce9aa09bf6a491c1a69 https://git.kernel.org/stable/c/2386e81a1d277f540e1285565c9d41d531bb69d4 https://git.kernel.org/stable/c/08eacbd141e2495d2fcdde84358a06c4f • CWE-416: Use After Free •