Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init<br /> <br /> The line cards array is not freed in the error path of<br /> mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by<br /> freeing the array in the error path, thereby making the error path<br /> identical to mlxsw_m_linecards_fini().

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.

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

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: exit gracefully if reloc roots don&amp;#39;t match<br /> <br /> [BUG]<br /> Syzbot reported a crash that an ASSERT() got triggered inside<br /> prepare_to_merge().<br /> <br /> [CAUSE]<br /> The root cause of the triggered ASSERT() is we can have a race between<br /> quota tree creation and relocation.<br /> <br /> This leads us to create a duplicated quota tree in the<br /> btrfs_read_fs_root() path, and since it&amp;#39;s treated as fs tree, it would<br /> have ROOT_SHAREABLE flag, causing us to create a reloc tree for it.<br /> <br /> The bug itself is fixed by a dedicated patch for it, but this already<br /> taught us the ASSERT() is not something straightforward for<br /> developers.<br /> <br /> [ENHANCEMENT]<br /> Instead of using an ASSERT(), let&amp;#39;s handle it gracefully and output<br /> extra info about the mismatch reloc roots to help debug.<br /> <br /> Also with the above ASSERT() removed, we can trigger ASSERT(0)s inside<br /> merge_reloc_roots() later.<br /> Also replace those ASSERT(0)s with WARN_ON()s.

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.

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.

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds<br /> <br /> Commit 56124d6c87fd ("fsverity: support enabling with tree block size f_mode &amp; FMODE_READ))&amp;#39; in __kernel_read() became<br /> reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called<br /> on a fd opened with access mode 3, which means "ioctl access only".<br /> <br /> Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But<br /> ioctl-only fds are a weird Linux extension that is rarely used and that<br /> few people even know about. (The documentation for FS_IOC_ENABLE_VERITY<br /> even specifically says it requires O_RDONLY.) It&amp;#39;s probably not<br /> worthwhile to make the ioctl internally open a new fd just to handle<br /> this case. Thus, just reject the ioctl on such fds for now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: pcn_uart: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.