CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47103 – inet: fully convert sk->sk_rx_dst to RCU rules
https://notcve.org/view.php?id=CVE-2021-47103
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->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->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->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: 2EXPL: 0CVE-2021-47102 – net: marvell: prestera: fix incorrect structure access
https://notcve.org/view.php?id=CVE-2021-47102
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix incorrect structure access In line: upper = info->upper_dev; We access upper_dev field, which is related only for particular events (e.g. event == NETDEV_CHANGEUPPER). So, this line cause invalid memory access for another events, when ptr is not netdev_notifier_changeupper_info. The KASAN logs are as follows: [ 30.123165] BUG: KASAN: stack-out-of-bounds in prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera] [ 30.133336] Read of size 8 at addr ffff80000cf772b0 by task udevd/778 [ 30.139866] [ 30.141398] CPU: 0 PID: 778 Comm: udevd Not tainted 5.16.0-rc3 #6 [ 30.147588] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 30.153056] Call trace: [ 30.155547] dump_backtrace+0x0/0x2c0 [ 30.159320] show_stack+0x18/0x30 [ 30.162729] dump_stack_lvl+0x68/0x84 [ 30.166491] print_address_description.constprop.0+0x74/0x2b8 [ 30.172346] kasan_report+0x1e8/0x250 [ 30.176102] __asan_load8+0x98/0xe0 [ 30.179682] prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera] [ 30.186847] prestera_netdev_event_handler+0x1b4/0x1c0 [prestera] [ 30.193313] raw_notifier_call_chain+0x74/0xa0 [ 30.197860] call_netdevice_notifiers_info+0x68/0xc0 [ 30.202924] register_netdevice+0x3cc/0x760 [ 30.207190] register_netdev+0x24/0x50 [ 30.211015] prestera_device_register+0x8a0/0xba0 [prestera] En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:marvell:prestera: corrige el acceso a la estructura incorrecta En línea: superior = info->upper_dev; Accedemos al campo Upper_dev, que está relacionado sólo para eventos particulares (por ejemplo, evento == NETDEV_CHANGEUPPER). Entonces, esta línea causa un acceso no válido a la memoria para otros eventos, cuando ptr no es netdev_notifier_changeupper_info. Los registros de KASAN son los siguientes: [30.123165] ERROR: KASAN: pila fuera de los límites en prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera] [30.133336] Lectura de tamaño 8 en la dirección ffff80000cf772b0 mediante tarea udevd/778 [ 0x0/0 x2c0 [ 30.159320] show_stack+0x18/0x30 [ 30.162729] dump_stack_lvl+0x68/0x84 [ 30.166491] print_address_description.constprop.0+0x74/0x2b8 [ 30.172346] kasan_report+0x1e8/0x250 [ 3 0.176102] __asan_load8+0x98/0xe0 [ 30.179682] prestera_netdev_port_event.constprop .0+0x68/0x538 [prestera] [ 30.186847] prestera_netdev_event_handler+0x1b4/0x1c0 [prestera] [ 30.193313] raw_notifier_call_chain+0x74/0xa0 [ 30.197860] call_netdevice_notifiers_info+0x68/0xc0 [ 30.202924] registro_netdevice+0x3cc/0x760 [ 30.207190] registro_netdev+0x24 /0x50 [ 30.211015] prestera_device_register+0x8a0/0xba0 [prestera] • https://git.kernel.org/stable/c/3d5048cc54bd250cfbb358c37fcc011135977887 https://git.kernel.org/stable/c/5c553a0cd1263e4da5f220d80fa713fc3959c1d0 https://git.kernel.org/stable/c/2efc2256febf214e7b2bdaa21fe6c3c3146acdcb •
CVSS: 6.0EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47101 – asix: fix uninit-value in asix_mdio_read()
https://notcve.org/view.php?id=CVE-2021-47101
In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: asix: corrige el valor uninit en asix_mdio_read() asix_read_cmd() puede leer menos que sizeof(smsr) bytes y en este caso smsr no estará inicializado. Registro de errores: ERROR: KMSAN: valor uninit en asix_check_host_enable drivers/net/usb/asix_common.c:82 [en línea] ERROR: KMSAN: valor uninit en asix_check_host_enable drivers/net/usb/asix_common.c:82 controladores [en línea] /net/usb/asix_common.c:497 ERROR: KMSAN: valor uninit en asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/ usb/asix_common.c:82 [en línea] controladores asix_check_host_enable/net/usb/asix_common.c:82 [en línea] controladores/net/usb/asix_common.c:497 controladores asix_mdio_read+0x3c1/0xb00/net/usb/asix_common.c :497 controladores/net/usb/asix_common.c:497 • https://git.kernel.org/stable/c/d9fe64e511144c1ee7d7555b4111f09dde9692ef https://git.kernel.org/stable/c/d259f621c85949f30cc578cac813b82bb5169f56 https://git.kernel.org/stable/c/8035b1a2a37a29d8c717ef84fca8fe7278bc9f03 https://access.redhat.com/security/cve/CVE-2021-47101 https://bugzilla.redhat.com/show_bug.cgi?id=2267916 • CWE-457: Use of Uninitialized Variable •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47100 – ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module
https://notcve.org/view.php?id=CVE-2021-47100
In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module Hi, When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko, the system crashed. The log as follows: [ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [ 141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP: 0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value. [ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000 [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 141.088009] PKRU: 55555554 [ 141.088009] Call Trace: [ 141.088009] ? process_one_work+0x195/0x390 [ 141.088009] ? worker_thread+0x30/0x390 [ 141.088009] ? process_one_work+0x390/0x390 [ 141.088009] ? kthread+0x10d/0x130 [ 141.088009] ? • https://git.kernel.org/stable/c/b2cfd8ab4add53c2070367bfee2f5b738f51698d https://git.kernel.org/stable/c/925229d552724e1bba1abf01d3a0b1318539b012 https://git.kernel.org/stable/c/992649b8b16843d27eb39ceea5f9cf85ffb50a18 https://git.kernel.org/stable/c/6809da5185141e61401da5b01896b79a4deed1ad https://git.kernel.org/stable/c/6b3f7e4b10f343f05b5fb513b07a9168fbf1172e https://git.kernel.org/stable/c/ffb76a86f8096a8206be03b14adda6092e18e275 •
CVSS: 6.0EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47099 – veth: ensure skb entering GRO are not cloned.
https://notcve.org/view.php?id=CVE-2021-47099
In the Linux kernel, the following vulnerability has been resolved: veth: ensure skb entering GRO are not cloned. After commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP"), if GRO is enabled on a veth device and TSO is disabled on the peer device, TCP skbs will go through the NAPI callback. If there is no XDP program attached, the veth code does not perform any share check, and shared/cloned skbs could enter the GRO engine. Ignat reported a BUG triggered later-on due to the above condition: [ 53.970529][ C1] kernel BUG at net/core/skbuff.c:3574! [ 53.981755][ C1] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI [ 53.982634][ C1] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc5+ #25 [ 53.982634][ C1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 53.982634][ C1] RIP: 0010:skb_shift+0x13ef/0x23b0 [ 53.982634][ C1] Code: ea 03 0f b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 41 0c 00 00 41 80 7f 02 00 4d 8d b5 d0 00 00 00 0f 85 74 f5 ff ff <0f> 0b 4d 8d 77 20 be 04 00 00 00 4c 89 44 24 78 4c 89 f7 4c 89 8c [ 53.982634][ C1] RSP: 0018:ffff8881008f7008 EFLAGS: 00010246 [ 53.982634][ C1] RAX: 0000000000000000 RBX: ffff8881180b4c80 RCX: 0000000000000000 [ 53.982634][ C1] RDX: 0000000000000002 RSI: ffff8881180b4d3c RDI: ffff88810bc9cac2 [ 53.982634][ C1] RBP: ffff8881008f70b8 R08: ffff8881180b4cf4 R09: ffff8881180b4cf0 [ 53.982634][ C1] R10: ffffed1022999e5c R11: 0000000000000002 R12: 0000000000000590 [ 53.982634][ C1] R13: ffff88810f940c80 R14: ffff88810f940d50 R15: ffff88810bc9cac0 [ 53.982634][ C1] FS: 0000000000000000(0000) GS:ffff888235880000(0000) knlGS:0000000000000000 [ 53.982634][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.982634][ C1] CR2: 00007ff5f9b86680 CR3: 0000000108ce8004 CR4: 0000000000170ee0 [ 53.982634][ C1] Call Trace: [ 53.982634][ C1] <TASK> [ 53.982634][ C1] tcp_sacktag_walk+0xaba/0x18e0 [ 53.982634][ C1] tcp_sacktag_write_queue+0xe7b/0x3460 [ 53.982634][ C1] tcp_ack+0x2666/0x54b0 [ 53.982634][ C1] tcp_rcv_established+0x4d9/0x20f0 [ 53.982634][ C1] tcp_v4_do_rcv+0x551/0x810 [ 53.982634][ C1] tcp_v4_rcv+0x22ed/0x2ed0 [ 53.982634][ C1] ip_protocol_deliver_rcu+0x96/0xaf0 [ 53.982634][ C1] ip_local_deliver_finish+0x1e0/0x2f0 [ 53.982634][ C1] ip_sublist_rcv_finish+0x211/0x440 [ 53.982634][ C1] ip_list_rcv_finish.constprop.0+0x424/0x660 [ 53.982634][ C1] ip_list_rcv+0x2c8/0x410 [ 53.982634][ C1] __netif_receive_skb_list_core+0x65c/0x910 [ 53.982634][ C1] netif_receive_skb_list_internal+0x5f9/0xcb0 [ 53.982634][ C1] napi_complete_done+0x188/0x6e0 [ 53.982634][ C1] gro_cell_poll+0x10c/0x1d0 [ 53.982634][ C1] __napi_poll+0xa1/0x530 [ 53.982634][ C1] net_rx_action+0x567/0x1270 [ 53.982634][ C1] __do_softirq+0x28a/0x9ba [ 53.982634][ C1] run_ksoftirqd+0x32/0x60 [ 53.982634][ C1] smpboot_thread_fn+0x559/0x8c0 [ 53.982634][ C1] kthread+0x3b9/0x490 [ 53.982634][ C1] ret_from_fork+0x22/0x30 [ 53.982634][ C1] </TASK> Address the issue by skipping the GRO stage for shared or cloned skbs. To reduce the chance of OoO, try to unclone the skbs before giving up. v1 -> v2: - use avoid skb_copy and fallback to netif_receive_skb - Eric En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: veth: asegúrese de que los skb que ingresan a GRO no estén clonados. Después de confirmar d3256efd8e8b ("veth: permitir habilitar NAPI incluso sin XDP"), si GRO está habilitado en un dispositivo veth y TSO está deshabilitado en el dispositivo par, los skbs TCP pasarán por la devolución de llamada de NAPI. Si no hay ningún programa XDP adjunto, el código veth no realiza ninguna verificación compartida y los skbs compartidos/clonados podrían ingresar al motor GRO. • https://git.kernel.org/stable/c/d3256efd8e8b234a6251e4d4580bd2c3c31fdc4c https://git.kernel.org/stable/c/d2269ae48598e05b59ec9ea9e6e44fd33941130d https://git.kernel.org/stable/c/9695b7de5b4760ed22132aca919570c0190cb0ce https://access.redhat.com/security/cve/CVE-2021-47099 https://bugzilla.redhat.com/show_bug.cgi?id=2267919 • CWE-20: Improper Input Validation •