Vulnerabilidades

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c<br /> <br /> The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can<br /> lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,<br /> which can lead to integer underflow. As a result, it leads to slab<br /> out-of-bound access.<br /> This patch adds back the IP_SET_HASH_WITH_NET0 macro to<br /> ip_set_hash_netportnet to address the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix zswap writeback race condition<br /> <br /> The zswap writeback mechanism can cause a race condition resulting in<br /> memory corruption, where a swapped out page gets swapped in with data that<br /> was written to a different page.<br /> <br /> The race unfolds like this:<br /> 1. a page with data A and swap offset X is stored in zswap<br /> 2. page A is removed off the LRU by zpool driver for writeback in<br /> zswap-shrink work, data for A is mapped by zpool driver<br /> 3. user space program faults and invalidates page entry A, offset X is<br /> considered free<br /> 4. kswapd stores page B at offset X in zswap (zswap could also be<br /> full, if so, page B would then be IOed to X, then skip step 5.)<br /> 5. entry A is replaced by B in tree-&gt;rbroot, this doesn&amp;#39;t affect the<br /> local reference held by zswap-shrink work<br /> 6. zswap-shrink work writes back A at X, and frees zswap entry A<br /> 7. swapin of slot X brings A in memory instead of B<br /> <br /> The fix:<br /> Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),<br /> zswap-shrink work just checks that the local zswap_entry reference is<br /> still the same as the one in the tree. If it&amp;#39;s not the same it means that<br /> it&amp;#39;s either been invalidated or replaced, in both cases the writeback is<br /> aborted because the local entry contains stale data.<br /> <br /> Reproducer:<br /> I originally found this by running `stress` overnight to validate my work<br /> on the zswap writeback mechanism, it manifested after hours on my test<br /> machine. The key to make it happen is having zswap writebacks, so<br /> whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do<br /> the trick.<br /> <br /> In order to reproduce this faster on a vm, I setup a system with ~100M of<br /> available memory and a 500M swap file, then running `stress --vm 1<br /> --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens<br /> of minutes. One can speed things up even more by swinging<br /> /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20<br /> and 1; this makes it reproduce in tens of seconds. It&amp;#39;s crucial to set<br /> `--vm-stride` to something other than 4096 otherwise `stress` won&amp;#39;t<br /> realize that memory has been corrupted because all pages would have the<br /> same data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Reinit port-&gt;pm on port specific driver unbind<br /> <br /> When we unbind a serial port hardware specific 8250 driver, the generic<br /> serial8250 driver takes over the port. After that we see an oops about 10<br /> seconds later. This can produce the following at least on some TI SoCs:<br /> <br /> Unhandled fault: imprecise external abort (0x1406)<br /> Internal error: : 1406 [#1] SMP ARM<br /> <br /> Turns out that we may still have the serial port hardware specific driver<br /> port-&gt;pm in use, and serial8250_pm() tries to call it after the port<br /> specific driver is gone:<br /> <br /> serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]<br /> uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]<br /> uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c<br /> __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c<br /> disassociate_ctty from do_exit+0x744/0xaac<br /> do_exit from do_group_exit+0x40/0x8c<br /> do_group_exit from __wake_up_parent+0x0/0x1c<br /> <br /> Let&amp;#39;s fix the issue by calling serial8250_set_defaults() in<br /> serial8250_unregister_port(). This will set the port back to using<br /> the serial8250 default functions, and sets the port-&gt;pm to point to<br /> serial8250_pm.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation<br /> <br /> When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI<br /> device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the<br /> device yet), doing a VM hibernation triggers a panic in<br /> hv_pci_restore_msi_msg() -&gt; msi_lock_descs(&amp;pdev-&gt;dev), because<br /> pdev-&gt;dev.msi.data is still NULL.<br /> <br /> Avoid the panic by checking if MSI-X/MSI is enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hi846: fix usage of pm_runtime_get_if_in_use()<br /> <br /> pm_runtime_get_if_in_use() does not only return nonzero values when<br /> the device is in use, it can return a negative errno too.<br /> <br /> And especially during resuming from system suspend, when runtime pm<br /> is not yet up again, -EAGAIN is being returned, so the subsequent<br /> pm_runtime_put() call results in a refcount underflow.<br /> <br /> Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to decrease the reference count in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().