CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47049 – Drivers: hv: vmbus: Use after free in __vmbus_open()
https://notcve.org/view.php?id=CVE-2021-47049
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Usar después de liberar en __vmbus_open() La variable "open_info" se agrega a &vmbus_connection.chn_msg_list, pero el manejo de errores libera "open_info" sin eliminarlo de la lista. Esto resultará en un uso posterior gratuito. • https://git.kernel.org/stable/c/6f3d791f300618caf82a2be0c27456edd76d5164 https://git.kernel.org/stable/c/6b32d45bd59982751beb8220e442b40b2706647f https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f https://git.kernel.org/stable/c/f37dd5d1b5d38a79a4f7b8dd7bbb705505f05560 https://git.kernel.org/stable/c/2728f289b3270b0e273292b46c534421a33bbfd5 https://git.kernel.org/stable/c/3e9bf43f7f7a46f21ec071cb47be92d0874c48da •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47046 – drm/amd/display: Fix off by one in hdmi_14_process_transaction()
https://notcve.org/view.php?id=CVE-2021-47046
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrección por uno en hdmi_14_process_transaction() La matriz hdcp_i2c_offsets[] no tenía una entrada para HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE, por lo que provocó un desbordamiento de lectura desactivado por uno. Agregué una entrada y copié el valor 0x0 para el desplazamiento de un código similar en drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. • https://git.kernel.org/stable/c/4c283fdac08abf3211533f70623c90a34f41d08d https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138 https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5 https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7 https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47043 – media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
https://notcve.org/view.php?id=CVE-2021-47043
In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: core: corrige algunas fugas de recursos en la ruta de error de 'venus_probe()' Si se produce un error después de una llamada exitosa a 'of_icc_get()', se debe deshacer . Utilice 'devm_of_icc_get()' en lugar de 'of_icc_get()' para evitar la fuga. Actualice la función de eliminación en consecuencia y elimine las llamadas 'icc_put()' ahora innecesarias. • https://git.kernel.org/stable/c/32f0a6ddc8c98a1aade2bf3d07c79d5d2c6ceb9a https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030 https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565 https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8 https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47041 – nvmet-tcp: fix incorrect locking in state_change sk callback
https://notcve.org/view.php?id=CVE-2021-47041
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5 https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47036 – udp: skip L4 aggregation for UDP tunnel packets
https://notcve.org/view.php?id=CVE-2021-47036
In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: omitir la agregación L4 para paquetes de túnel UDP Si NETIF_F_GRO_FRAGLIST o NETIF_F_GRO_UDP_FWD están habilitados y hay túneles UDP disponibles en el sistema, udp_gro_receive() podría terminar realizando la agregación L4 (ya sea SKB_GSO_UDP_L4 o SKB_GSO_FRAGLIST) en el nivel del túnel UDP externo para paquetes que transportan efectivamente un encabezado de túnel UDP. Eso podría causar corrupción del protocolo interno. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/450687386cd16d081b58cd7a342acff370a96078 https://git.kernel.org/stable/c/18f25dc399901426dff61e676ba603ff52c666f7 •