Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: If sock is dead don&amp;#39;t access sock&amp;#39;s sk_wq in sk_stream_wait_memory<br /> <br /> Fixes the below NULL pointer dereference:<br /> <br /> [...]<br /> [ 14.471200] Call Trace:<br /> [ 14.471562] <br /> [ 14.471882] lock_acquire+0x245/0x2e0<br /> [ 14.472416] ? remove_wait_queue+0x12/0x50<br /> [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50<br /> [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50<br /> [ 14.474318] ? remove_wait_queue+0x12/0x50<br /> [ 14.474907] remove_wait_queue+0x12/0x50<br /> [ 14.475480] sk_stream_wait_memory+0x20d/0x340<br /> [ 14.476127] ? do_wait_intr_irq+0x80/0x80<br /> [ 14.476704] do_tcp_sendpages+0x287/0x600<br /> [ 14.477283] tcp_bpf_push+0xab/0x260<br /> [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500<br /> [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0<br /> [ 14.479096] tcp_bpf_send_verdict+0x105/0x470<br /> [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0<br /> [ 14.480311] sock_sendmsg+0x2d/0x40<br /> [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0<br /> [ 14.481390] ? copy_msghdr_from_user+0x62/0x80<br /> [ 14.482048] ___sys_sendmsg+0x78/0xb0<br /> [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150<br /> [ 14.483215] ? __do_fault+0x2a/0x1a0<br /> [ 14.483738] ? do_fault+0x15e/0x5d0<br /> [ 14.484246] ? __handle_mm_fault+0x56b/0x1040<br /> [ 14.484874] ? lock_is_held_type+0xdf/0x130<br /> [ 14.485474] ? find_held_lock+0x2d/0x90<br /> [ 14.486046] ? __sys_sendmsg+0x41/0x70<br /> [ 14.486587] __sys_sendmsg+0x41/0x70<br /> [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350<br /> [ 14.487822] do_syscall_64+0x34/0x80<br /> [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> The test scenario has the following flow:<br /> <br /> thread1 thread2<br /> ----------- ---------------<br /> tcp_bpf_sendmsg<br /> tcp_bpf_send_verdict<br /> tcp_bpf_sendmsg_redir sock_close<br /> tcp_bpf_push_locked __sock_release<br /> tcp_bpf_push //inet_release<br /> do_tcp_sendpages sock-&gt;ops-&gt;release<br /> sk_stream_wait_memory // tcp_close<br /> sk_wait_event sk-&gt;sk_prot-&gt;close<br /> release_sock(__sk);<br /> ***<br /> lock_sock(sk);<br /> __tcp_close<br /> sock_orphan(sk)<br /> sk-&gt;sk_wq = NULL<br /> release_sock<br /> ****<br /> lock_sock(__sk);<br /> remove_wait_queue(sk_sleep(sk), &amp;wait);<br /> sk_sleep(sk)<br /> //NULL pointer dereference<br /> &amp;rcu_dereference_raw(sk-&gt;sk_wq)-&gt;wait<br /> <br /> While waiting for memory in thread1, the socket is released with its wait<br /> queue because thread2 has closed it. This caused by tcp_bpf_send_verdict<br /> didn&amp;#39;t increase the f_count of psock-&gt;sk_redir-&gt;sk_socket-&gt;file in thread1.<br /> <br /> We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory<br /> before accessing the wait queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()<br /> <br /> &gt; ret = brcmf_proto_tx_queue_data(drvr, ifp-&gt;ifidx, skb);<br /> <br /> may be schedule, and then complete before the line<br /> <br /> &gt; ndev-&gt;stats.tx_bytes += skb-&gt;len;<br /> <br /> [ 46.912801] ==================================================================<br /> [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]<br /> [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328<br /> [ 46.935991]<br /> [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1<br /> [ 46.947255] Hardware name: [REDACTED]<br /> [ 46.954568] Call trace:<br /> [ 46.957037] dump_backtrace+0x0/0x2b8<br /> [ 46.960719] show_stack+0x24/0x30<br /> [ 46.964052] dump_stack+0x128/0x194<br /> [ 46.967557] print_address_description.isra.0+0x64/0x380<br /> [ 46.972877] __kasan_report+0x1d4/0x240<br /> [ 46.976723] kasan_report+0xc/0x18<br /> [ 46.980138] __asan_report_load4_noabort+0x18/0x20<br /> [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]<br /> [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0<br /> [ 46.994894] sch_direct_xmit+0x198/0xd08<br /> [ 46.998827] __qdisc_run+0x37c/0x1dc0<br /> [ 47.002500] __dev_queue_xmit+0x1528/0x21f8<br /> [ 47.006692] dev_queue_xmit+0x24/0x30<br /> [ 47.010366] neigh_resolve_output+0x37c/0x678<br /> [ 47.014734] ip_finish_output2+0x598/0x2458<br /> [ 47.018927] __ip_finish_output+0x300/0x730<br /> [ 47.023118] ip_output+0x2e0/0x430<br /> [ 47.026530] ip_local_out+0x90/0x140<br /> [ 47.030117] igmpv3_sendpack+0x14c/0x228<br /> [ 47.034049] igmpv3_send_cr+0x384/0x6b8<br /> [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118<br /> [ 47.042262] call_timer_fn+0x1cc/0xbe8<br /> [ 47.046021] __run_timers+0x4d8/0xb28<br /> [ 47.049693] run_timer_softirq+0x24/0x40<br /> [ 47.053626] __do_softirq+0x2c0/0x117c<br /> [ 47.057387] irq_exit+0x2dc/0x388<br /> [ 47.060715] __handle_domain_irq+0xb4/0x158<br /> [ 47.064908] gic_handle_irq+0x58/0xb0<br /> [ 47.068581] el0_irq_naked+0x50/0x5c<br /> [ 47.072162]<br /> [ 47.073665] Allocated by task 328:<br /> [ 47.077083] save_stack+0x24/0xb0<br /> [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0<br /> [ 47.084776] kasan_slab_alloc+0x14/0x20<br /> [ 47.088622] kmem_cache_alloc+0x15c/0x468<br /> [ 47.092643] __alloc_skb+0xa4/0x498<br /> [ 47.096142] igmpv3_newpack+0x158/0xd78<br /> [ 47.099987] add_grhead+0x210/0x288<br /> [ 47.103485] add_grec+0x6b0/0xb70<br /> [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8<br /> [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118<br /> [ 47.115027] call_timer_fn+0x1cc/0xbe8<br /> [ 47.118785] __run_timers+0x4d8/0xb28<br /> [ 47.122457] run_timer_softirq+0x24/0x40<br /> [ 47.126389] __do_softirq+0x2c0/0x117c<br /> [ 47.130142]<br /> [ 47.131643] Freed by task 180:<br /> [ 47.134712] save_stack+0x24/0xb0<br /> [ 47.138041] __kasan_slab_free+0x108/0x180<br /> [ 47.142146] kasan_slab_free+0x10/0x18<br /> [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0<br /> [ 47.150444] kmem_cache_free+0x8c/0x528<br /> [ 47.154292] kfree_skbmem+0x94/0x108<br /> [ 47.157880] consume_skb+0x10c/0x5a8<br /> [ 47.161466] __dev_kfree_skb_any+0x88/0xa0<br /> [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]<br /> [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac]<br /> [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]<br /> [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]<br /> [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]<br /> [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]<br /> [ 47.197859] process_one_work+0x7fc/0x1a80<br /> [ 47.201965] worker_thread+0x31c/0xc40<br /> [ 47.205726] kthread+0x2d8/0x370<br /> [ 47.208967] ret_from_fork+0x10/0x18<br /> [ 47.212546]<br /> [ 47.214051] The buggy address belongs to the object at ffffff803f588280<br /> [ 47.214051] which belongs to the cache skbuff_head_cache of size 208<br /> [ 47.227086] The buggy address is located 104 bytes inside of<br /> [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)<br /> [ 47.238814] The buggy address belongs to the page:<br /> [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv2 READ<br /> <br /> Since before the git era, NFSD has conserved the number of pages<br /> held by each nfsd thread by combining the RPC receive and send<br /> buffers into a single array of pages. This works because there are<br /> no cases where an operation needs a large RPC Call message and a<br /> large RPC Reply at the same time.<br /> <br /> Once an RPC Call has been received, svc_process() updates<br /> svc_rqst::rq_res to describe the part of rq_pages that can be<br /> used for constructing the Reply. This means that the send buffer<br /> (rq_res) shrinks when the received RPC record containing the RPC<br /> Call is large.<br /> <br /> A client can force this shrinkage on TCP by sending a correctly-<br /> formed RPC Call header contained in an RPC record that is<br /> excessively large. The full maximum payload size cannot be<br /> constructed in that case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Fix error code path in acpi_ds_call_control_method()<br /> <br /> A use-after-free in acpi_ps_parse_aml() after a failing invocaion of<br /> acpi_ds_call_control_method() is reported by KASAN [1] and code<br /> inspection reveals that next_walk_state pushed to the thread by<br /> acpi_ds_create_walk_state() is freed on errors, but it is not popped<br /> from the thread beforehand. Thus acpi_ds_get_current_walk_state()<br /> called by acpi_ps_parse_aml() subsequently returns it as the new<br /> walk state which is incorrect.<br /> <br /> To address this, make acpi_ds_call_control_method() call<br /> acpi_ds_pop_walk_state() to pop next_walk_state from the thread before<br /> returning an error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: adv7511: unregister cec i2c device after cec adapter<br /> <br /> cec_unregister_adapter() assumes that the underlying adapter ops are<br /> callable. For example, if the CEC adapter currently has a valid physical<br /> address, then the unregistration procedure will invalidate the physical<br /> address by setting it to f.f.f.f. Whence the following kernel oops<br /> observed after removing the adv7511 module:<br /> <br /> Unable to handle kernel execution of user memory at virtual address 0000000000000000<br /> Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP<br /> Call trace:<br /> 0x0<br /> adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511]<br /> cec_adap_unconfigure+0x44/0x90 [cec]<br /> __cec_s_phys_addr.part.0+0x68/0x230 [cec]<br /> __cec_s_phys_addr+0x40/0x50 [cec]<br /> cec_unregister_adapter+0xb4/0x118 [cec]<br /> adv7511_remove+0x60/0x90 [adv7511]<br /> i2c_device_remove+0x34/0xe0<br /> device_release_driver_internal+0x114/0x1f0<br /> driver_detach+0x54/0xe0<br /> bus_remove_driver+0x60/0xd8<br /> driver_unregister+0x34/0x60<br /> i2c_del_driver+0x2c/0x68<br /> adv7511_exit+0x1c/0x67c [adv7511]<br /> __arm64_sys_delete_module+0x154/0x288<br /> invoke_syscall+0x48/0x100<br /> el0_svc_common.constprop.0+0x48/0xe8<br /> do_el0_svc+0x28/0x88<br /> el0_svc+0x1c/0x50<br /> el0t_64_sync_handler+0xa8/0xb0<br /> el0t_64_sync+0x15c/0x160<br /> Code: bad PC value<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Protect against this scenario by unregistering i2c_cec after<br /> unregistering the CEC adapter. Duly disable the CEC clock afterwards<br /> too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix use-after-free<br /> <br /> We&amp;#39;ve already freed the assoc_data at this point, so need<br /> to use another copy of the AP (MLD) address instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails<br /> <br /> fcoe_init() calls fcoe_transport_attach(&amp;fcoe_sw_transport), but when<br /> fcoe_if_init() fails, &amp;fcoe_sw_transport is not detached and leaves freed<br /> &amp;fcoe_sw_transport on fcoe_transports list. This causes panic when<br /> reinserting module.<br /> <br /> BUG: unable to handle page fault for address: fffffbfff82e2213<br /> RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]<br /> Call Trace:<br /> <br /> do_one_initcall+0xd0/0x4e0<br /> load_module+0x5eee/0x7210<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: led: Fix potential null-ptr-deref in start_task()<br /> <br /> start_task() calls create_singlethread_workqueue() and not checked the<br /> ret value, which may return NULL. And a null-ptr-deref may happen:<br /> <br /> start_task()<br /> create_singlethread_workqueue() # failed, led_wq is NULL<br /> queue_delayed_work()<br /> queue_delayed_work_on()<br /> __queue_delayed_work() # warning here, but continue<br /> __queue_work() # access wq-&gt;flags, null-ptr-deref<br /> <br /> Check the ret value and return -ENOMEM if it is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()<br /> <br /> If of_iomap() failed, &amp;#39;aic&amp;#39; should be freed before return. Otherwise<br /> there is a memory leak.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/md/md-bitmap: check the return value of md_bitmap_get_counter()<br /> <br /> Check the return value of md_bitmap_get_counter() in case it returns<br /> NULL pointer, which will result in a null pointer dereference.<br /> <br /> v2: update the check to include other dereference

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tunnel: wait until all sk_user_data reader finish before releasing the sock<br /> <br /> There is a race condition in vxlan that when deleting a vxlan device<br /> during receiving packets, there is a possibility that the sock is<br /> released after getting vxlan_sock vs from sk_user_data. Then in<br /> later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got<br /> NULL pointer dereference. e.g.<br /> <br /> #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757<br /> #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d<br /> #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48<br /> #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b<br /> #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb<br /> #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542<br /> #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62<br /> [exception RIP: vxlan_ecn_decapsulate+0x3b]<br /> RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246<br /> RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000<br /> RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700<br /> RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae<br /> R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700<br /> R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]<br /> #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507<br /> #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45<br /> #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807<br /> #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951<br /> #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde<br /> #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b<br /> #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139<br /> #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a<br /> #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3<br /> #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca<br /> #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3<br /> <br /> Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh<br /> <br /> Fix this by waiting for all sk_user_data reader to finish before<br /> releasing the sock.