Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix memory leaks in error path<br /> <br /> The memory allocated by vxlan_vnigroup_init() is not freed in the error<br /> path, leading to memory leaks [1]. Fix by calling<br /> vxlan_vnigroup_uninit() in the error path.<br /> <br /> The leaks can be reproduced by annotating gro_cells_init() with<br /> ALLOW_ERROR_INJECTION() and then running:<br /> <br /> # echo "100" &gt; /sys/kernel/debug/fail_function/probability<br /> # echo "1" &gt; /sys/kernel/debug/fail_function/times<br /> # echo "gro_cells_init" &gt; /sys/kernel/debug/fail_function/inject<br /> # printf %#x -12 &gt; /sys/kernel/debug/fail_function/gro_cells_init/retval<br /> # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter<br /> RTNETLINK answers: Cannot allocate memory<br /> <br /> [1]<br /> unreferenced object 0xffff88810db84a00 (size 512):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............<br /> 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0x60<br /> [] vxlan_vnigroup_init+0x4c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90<br /> [] ___sys_sendmsg+0x13a/0x1e0<br /> [] __sys_sendmsg+0x11c/0x1f0<br /> [] do_syscall_64+0x38/0x80<br /> unreferenced object 0xffff88810e76d5f8 (size 192):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....<br /> 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x90<br /> [] kvmalloc_node+0xa6/0x1f0<br /> [] bucket_table_alloc.isra.0+0x83/0x460<br /> [] rhashtable_init+0x43b/0x7c0<br /> [] vxlan_vnigroup_init+0x6c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/addrconf: fix a potential refcount underflow for idev<br /> <br /> Now in addrconf_mod_rs_timer(), reference idev depends on whether<br /> rs_timer is not pending. Then modify rs_timer timeout.<br /> <br /> There is a time gap in [1], during which if the pending rs_timer<br /> becomes not pending. It will miss to hold idev, but the rs_timer<br /> is activated. Thus rs_timer callback function addrconf_rs_timer()<br /> will be executed and put idev later without holding idev. A refcount<br /> underflow issue for idev can be caused by this.<br /> <br /> if (!timer_pending(&amp;idev-&gt;rs_timer))<br /> in6_dev_hold(idev);<br /> rs_timer, jiffies + when);<br /> <br /> To fix the issue, hold idev if mod_timer() return 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix race on port output<br /> <br /> assume the following setup on a single machine:<br /> 1. An openvswitch instance with one bridge and default flows<br /> 2. two network namespaces "server" and "client"<br /> 3. two ovs interfaces "server" and "client" on the bridge<br /> 4. for each ovs interface a veth pair with a matching name and 32 rx and<br /> tx queues<br /> 5. move the ends of the veth pairs to the respective network namespaces<br /> 6. assign ip addresses to each of the veth ends in the namespaces (needs<br /> to be the same subnet)<br /> 7. start some http server on the server network namespace<br /> 8. test if a client in the client namespace can reach the http server<br /> <br /> when following the actions below the host has a chance of getting a cpu<br /> stuck in a infinite loop:<br /> 1. send a large amount of parallel requests to the http server (around<br /> 3000 curls should work)<br /> 2. in parallel delete the network namespace (do not delete interfaces or<br /> stop the server, just kill the namespace)<br /> <br /> there is a low chance that this will cause the below kernel cpu stuck<br /> message. If this does not happen just retry.<br /> Below there is also the output of bpftrace for the functions mentioned<br /> in the output.<br /> <br /> The series of events happening here is:<br /> 1. the network namespace is deleted calling<br /> `unregister_netdevice_many_notify` somewhere in the process<br /> 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and<br /> then runs `synchronize_net`<br /> 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`<br /> 4. this is then handled by `dp_device_event` which calls<br /> `ovs_netdev_detach_dev` (if a vport is found, which is the case for<br /> the veth interface attached to ovs)<br /> 5. this removes the rx_handlers of the device but does not prevent<br /> packages to be sent to the device<br /> 6. `dp_device_event` then queues the vport deletion to work in<br /> background as a ovs_lock is needed that we do not hold in the<br /> unregistration path<br /> 7. `unregister_netdevice_many_notify` continues to call<br /> `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0<br /> 8. port deletion continues (but details are not relevant for this issue)<br /> 9. at some future point the background task deletes the vport<br /> <br /> If after 7. but before 9. a packet is send to the ovs vport (which is<br /> not deleted at this point in time) which forwards it to the<br /> `dev_queue_xmit` flow even though the device is unregistering.<br /> In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is<br /> a while loop (if the packet has a rx_queue recorded) that is infinite if<br /> `dev-&gt;real_num_tx_queues` is zero.<br /> <br /> To prevent this from happening we update `do_output` to handle devices<br /> without carrier the same as if the device is not found (which would<br /> be the code path after 9. is done).<br /> <br /> Additionally we now produce a warning in `skb_tx_hash` if we will hit<br /> the infinite loop.<br /> <br /> bpftrace (first word is function name):<br /> <br /> __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2<br /> ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2<br /> netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> dp_<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix potential memory leak<br /> <br /> Function dwc3_qcom_probe() allocates memory for resource structure<br /> which is pointed by parent_res pointer. This memory is not<br /> freed. This leads to memory leak. Use stack memory to prevent<br /> memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** 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 /> btrfs: fix use-after-free of new block group that became unused<br /> <br /> If a task creates a new block group and that block group becomes unused<br /> before we finish its creation, at btrfs_create_pending_block_groups(),<br /> then when btrfs_mark_bg_unused() is called against the block group, we<br /> assume that the block group is currently in the list of block groups to<br /> reclaim, and we move it out of the list of new block groups and into the<br /> list of unused block groups. This has two consequences:<br /> <br /> 1) We move it out of the list of new block groups associated to the<br /> current transaction. So the block group creation is not finished and<br /> if we attempt to delete the bg because it&amp;#39;s unused, we will not find<br /> the block group item in the extent tree (or the new block group tree),<br /> its device extent items in the device tree etc, resulting in the<br /> deletion to fail due to the missing items;<br /> <br /> 2) We don&amp;#39;t increment the reference count on the block group when we<br /> move it to the list of unused block groups, because we assumed the<br /> block group was on the list of block groups to reclaim, and in that<br /> case it already has the correct reference count. However the block<br /> group was on the list of new block groups, in which case no extra<br /> reference was taken because it&amp;#39;s local to the current task. This<br /> later results in doing an extra reference count decrement when<br /> removing the block group from the unused list, eventually leading the<br /> reference count to 0.<br /> <br /> This second case was caught when running generic/297 from fstests, which<br /> produced the following assertion failure and stack trace:<br /> <br /> [589.559] assertion failed: refcount_read(&amp;block_group-&gt;refs) == 1, in fs/btrfs/block-group.c:4299<br /> [589.559] ------------[ cut here ]------------<br /> [589.559] kernel BUG at fs/btrfs/block-group.c:4299!<br /> [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.561] Code: 68 62 da c0 (...)<br /> [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246<br /> [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000<br /> [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff<br /> [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50<br /> [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00<br /> [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100<br /> [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000<br /> [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0<br /> [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [589.564] Call Trace:<br /> [589.564] <br /> [589.565] ? __die_body+0x1b/0x60<br /> [589.565] ? die+0x39/0x60<br /> [589.565] ? do_trap+0xeb/0x110<br /> [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? do_error_trap+0x6a/0x90<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? exc_invalid_op+0x4e/0x70<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? asm_exc_invalid_op+0x16/0x20<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] close_ctree+0x35d/0x560 [btrfs]<br /> [589.568] ? fsnotify_sb_delete+0x13e/0x1d0<br /> [589.568] ? dispose_list+0x3a/0x50<br /> [589.568] ? evict_inodes+0x151/0x1a0<br /> [589.568] generic_shutdown_super+0x73/0x1a0<br /> [589.569] kill_anon_super+0x14/0x30<br /> [589.569] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [589.569] deactivate_locked<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: Fix a race between coalescing and releasing SKBs<br /> <br /> Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment<br /> recycling") allowed coalescing to proceed with non page pool page and page<br /> pool page when @from is cloned, i.e.<br /> <br /> to-&gt;pp_recycle --&gt; false<br /> from-&gt;pp_recycle --&gt; true<br /> skb_cloned(from) --&gt; true<br /> <br /> However, it actually requires skb_cloned(@from) to hold true until<br /> coalescing finishes in this situation. If the other cloned SKB is<br /> released while the merging is in process, from_shinfo-&gt;nr_frags will be<br /> set to 0 toward the end of the function, causing the increment of frag<br /> page _refcount to be unexpectedly skipped resulting in inconsistent<br /> reference counts. Later when SKB(@to) is released, it frees the page<br /> directly even though the page pool page is still in use, leading to<br /> use-after-free or double-free errors. So it should be prohibited.<br /> <br /> The double-free error message below prompted us to investigate:<br /> BUG: Bad page state in process swapper/1 pfn:0e0d1<br /> page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000<br /> index:0x2 pfn:0xe0d1<br /> flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000<br /> raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000<br /> page dumped because: nonzero _refcount<br /> <br /> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> bad_page+0x69/0xf0<br /> free_pcp_prepare+0x260/0x2f0<br /> free_unref_page+0x20/0x1c0<br /> skb_release_data+0x10b/0x1a0<br /> napi_consume_skb+0x56/0x150<br /> net_rx_action+0xf0/0x350<br /> ? __napi_schedule+0x79/0x90<br /> __do_softirq+0xc8/0x2b1<br /> __irq_exit_rcu+0xb9/0xf0<br /> common_interrupt+0x82/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:default_idle+0xb/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: don&amp;#39;t allow to overwrite ENDPOINT0 attributes<br /> <br /> A bad USB device is able to construct a service connection response<br /> message with target endpoint being ENDPOINT0 which is reserved for<br /> HTC_CTRL_RSVD_SVC and should not be modified to be used for any other<br /> services.<br /> <br /> Reject such service connection responses.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Avoid undefined behavior: applying zero offset to null pointer<br /> <br /> ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e<br /> <br /> Before this change we see the following UBSAN stack trace in Fuchsia:<br /> <br /> #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302<br /> #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 +0x3d77f<br /> #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 +0x3d77f<br /> #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 +0x3d77f<br /> #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 +0x4196d<br /> #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 +0x4150d<br /> #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302<br /> #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 +0x262369<br /> #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 +0x2b7fac<br /> #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 +0x2c64d2<br /> #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 +0x22a052<br /> #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 +0x293dd8<br /> #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 +0x2a9e98<br /> #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 +0x2931ac<br /> #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 +0x2fc40d<br /> #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 +0xed603<br /> <br /> Add a simple check that avoids incrementing a pointer by zero, but<br /> otherwise behaves as before. Note that our findings are against ACPICA<br /> 20221020, but the same code exists on master.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/dma-resv: Stop leaking on krealloc() failure<br /> <br /> Currently dma_resv_get_fences() will leak the previously<br /> allocated array if the fence iteration got restarted and<br /> the krealloc_array() fails.<br /> <br /> Free the old array by hand, and make sure we still clear<br /> the returned *fences so the caller won&amp;#39;t end up accessing<br /> freed memory. Some (but not all) of the callers of<br /> dma_resv_get_fences() seem to still trawl through the<br /> array even when dma_resv_get_fences() failed. And let&amp;#39;s<br /> zero out *num_fences as well for good measure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Avoid NULL pointer access during management transmit cleanup<br /> <br /> Currently &amp;#39;ar&amp;#39; reference is not added in skb_cb.<br /> Though this is generally not used during transmit completion<br /> callbacks, on interface removal the remaining idr cleanup callback<br /> uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them<br /> during transmit call for proper usage to avoid NULL pointer dereference.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/sme: Set new vector length before reallocating<br /> <br /> As part of fixing the allocation of the buffer for SVE state when changing<br /> SME vector length we introduced an immediate reallocation of the SVE state,<br /> this is also done when changing the SVE vector length for consistency.<br /> Unfortunately this reallocation is done prior to writing the new vector<br /> length to the task struct, meaning the allocation is done with the old<br /> vector length and can lead to memory corruption due to an undersized buffer<br /> being used.<br /> <br /> Move the update of the vector length before the allocation to ensure that<br /> the new vector length is taken into account.<br /> <br /> For some reason this isn&amp;#39;t triggering any problems when running tests on<br /> the arm64 fixes branch (even after repeated tries) but is triggering<br /> issues very often after merge into mainline.