Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In esd_usb_open(), the URBs for USB-in transfers are allocated, added to<br /> the dev-&gt;rx_submitted anchor and submitted. In the complete callback<br /> esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> esd_usb_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in esd_usb_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> esd_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Fix potential OOB access in audio mixer handling<br /> <br /> In the audio mixer handling code of ctxfi driver, the conf field is<br /> used as a kind of loop index, and it&amp;#39;s referred in the index callbacks<br /> (amixer_index() and sum_index()).<br /> <br /> As spotted recently by fuzzers, the current code causes OOB access at<br /> those functions.<br /> | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48<br /> | index 8 is out of range for type &amp;#39;unsigned char [8]&amp;#39;<br /> <br /> After the analysis, the cause was found to be the lack of the proper<br /> (re-)initialization of conj field.<br /> <br /> This patch addresses those OOB accesses by adding the proper<br /> initializations of the loop indices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge<br /> <br /> Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted<br /> merge", v2.<br /> <br /> Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA<br /> merges") introduced the ability to merge previously unavailable VMA merge<br /> scenarios.<br /> <br /> However, it is handling merges incorrectly when it comes to mremap() of a<br /> faulted VMA adjacent to an unfaulted VMA. The issues arise in three<br /> cases:<br /> <br /> 1. Previous VMA unfaulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|<br /> | unfaulted |(faulted VMA)|<br /> |-----------|.............|<br /> prev<br /> <br /> 2. Next VMA unfaulted:<br /> <br /> copied -----|<br /> v<br /> |.............|-----------|<br /> |(faulted VMA)| unfaulted |<br /> |.............|-----------|<br /> next<br /> <br /> 3. Both adjacent VMAs unfaulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|-----------|<br /> | unfaulted |(faulted VMA)| unfaulted |<br /> |-----------|.............|-----------|<br /> prev next<br /> <br /> This series fixes each of these cases, and introduces self tests to assert<br /> that the issues are corrected.<br /> <br /> I also test a further case which was already handled, to assert that my<br /> changes continues to correctly handle it:<br /> <br /> 4. prev unfaulted, next faulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|-----------|<br /> | unfaulted |(faulted VMA)| faulted |<br /> |-----------|.............|-----------|<br /> prev next<br /> <br /> This bug was discovered via a syzbot report, linked to in the first patch<br /> in the series, I confirmed that this series fixes the bug.<br /> <br /> I also discovered that we are failing to check that the faulted VMA was<br /> not forked when merging a copied VMA in cases 1-3 above, an issue this<br /> series also addresses.<br /> <br /> I also added self tests to assert that this is resolved (and confirmed<br /> that the tests failed prior to this).<br /> <br /> I also cleaned up vma_expand() as part of this work, renamed<br /> vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was<br /> unduly confusing, and simplified the comments around this function.<br /> <br /> <br /> This patch (of 4):<br /> <br /> Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA<br /> merges") introduced the ability to merge previously unavailable VMA merge<br /> scenarios.<br /> <br /> The key piece of logic introduced was the ability to merge a faulted VMA<br /> immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to<br /> correctly handle anon_vma state.<br /> <br /> In the case of the merge of an existing VMA (that is changing properties<br /> of a VMA and then merging if those properties are shared by adjacent<br /> VMAs), dup_anon_vma() is invoked correctly.<br /> <br /> However in the case of the merge of a new VMA, a corner case peculiar to<br /> mremap() was missed.<br /> <br /> The issue is that vma_expand() only performs dup_anon_vma() if the target<br /> (the VMA that will ultimately become the merged VMA): is not the next VMA,<br /> i.e. the one that appears after the range in which the new VMA is to be<br /> established.<br /> <br /> A key insight here is that in all other cases other than mremap(), a new<br /> VMA merge either expands an existing VMA, meaning that the target VMA will<br /> be that VMA, or would have anon_vma be NULL.<br /> <br /> Specifically:<br /> <br /> * __mmap_region() - no anon_vma in place, initial mapping.<br /> * do_brk_flags() - expanding an existing VMA.<br /> * vma_merge_extend() - expanding an existing VMA.<br /> * relocate_vma_down() - no anon_vma in place, initial mapping.<br /> <br /> In addition, we are in the unique situation of needing to duplicate<br /> anon_vma state from a VMA that is neither the previous or next VMA being<br /> merged with.<br /> <br /> dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted<br /> case. This leaves four possibilities, in each case where the copied VMA<br /> is faulted:<br /> <br /> 1. Previous VMA unfaulted:<br /> <br /> copied -----|<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: scarlett2: Fix buffer overflow in config retrieval<br /> <br /> The scarlett2_usb_get_config() function has a logic error in the<br /> endianness conversion code that can cause buffer overflows when<br /> count &gt; 1.<br /> <br /> The code checks `if (size == 2)` where `size` is the total buffer size in<br /> bytes, then loops `count` times treating each element as u16 (2 bytes).<br /> This causes the loop to access `count * 2` bytes when the buffer only<br /> has `size` bytes allocated.<br /> <br /> Fix by checking the element size (config_item-&gt;size) instead of the<br /> total buffer size. This ensures the endianness conversion matches the<br /> actual element type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: cdev: Fix resource leaks on errors in lineinfo_changed_notify()<br /> <br /> On error handling paths, lineinfo_changed_notify() doesn&amp;#39;t free the<br /> allocated resources which results leaks. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In mcba_usb_probe() -&gt; mcba_usb_start(), the URBs for USB-in transfers are<br /> allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the<br /> complete callback mcba_usb_read_bulk_callback(), the URBs are processed and<br /> resubmitted. In mcba_usb_close() -&gt; mcba_urb_unlink() the URBs are freed by<br /> calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in usb_kill_anchored_urbs().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> mcba_usb_read_bulk_callback()to the priv-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: intel-xway: fix OF node refcount leakage<br /> <br /> Automated review spotted am OF node reference count leakage when<br /> checking if the &amp;#39;leds&amp;#39; child node exists.<br /> <br /> Call of_put_node() to correctly maintain the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ife: avoid possible NULL deref<br /> <br /> tcf_ife_encode() must make sure ife_encode() does not return NULL.<br /> <br /> syzbot reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166<br /> CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)<br /> Call Trace:<br /> <br /> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101<br /> tcf_ife_encode net/sched/act_ife.c:841 [inline]<br /> tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877<br /> tc_act include/net/tc_wrapper.h:130 [inline]<br /> tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152<br /> tcf_exts_exec include/net/pkt_cls.h:349 [inline]<br /> mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42<br /> tc_classify include/net/tc_wrapper.h:197 [inline]<br /> __tcf_classify net/sched/cls_api.c:1764 [inline]<br /> tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860<br /> multiq_classify net/sched/sch_multiq.c:39 [inline]<br /> multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66<br /> dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147<br /> __dev_xmit_skb net/core/dev.c:4262 [inline]<br /> __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: Fix memory leak in wbrf_record()<br /> <br /> The tmp buffer is allocated using kcalloc() but is not freed if<br /> acpi_evaluate_dsm() fails. This causes a memory leak in the error path.<br /> <br /> Fix this by explicitly freeing the tmp buffer in the error handling<br /> path of acpi_evaluate_dsm().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix recvmsg() unconditional requeue<br /> <br /> If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at<br /> the front of the recvmsg queue already has its mutex locked, it requeues<br /> the call - whether or not the call is already queued. The call may be on<br /> the queue because MSG_PEEK was also passed and so the call was not dequeued<br /> or because the I/O thread requeued it.<br /> <br /> The unconditional requeue may then corrupt the recvmsg queue, leading to<br /> things like UAFs or refcount underruns.<br /> <br /> Fix this by only requeuing the call if it isn&amp;#39;t already on the queue - and<br /> moving it to the front if it is already queued. If we don&amp;#39;t queue it, we<br /> have to put the ref we obtained by dequeuing it.<br /> <br /> Also, MSG_PEEK doesn&amp;#39;t dequeue the call so shouldn&amp;#39;t call<br /> rxrpc_notify_socket() for the call if we didn&amp;#39;t use up all the data on the<br /> queue, so fix that also.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/io-pgtable-arm: fix size_t signedness bug in unmap path<br /> <br /> __arm_lpae_unmap() returns size_t but was returning -ENOENT (negative<br /> error code) when encountering an unmapped PTE. Since size_t is unsigned,<br /> -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE<br /> on 64-bit systems).<br /> <br /> This corrupted value propagates through the call chain:<br /> __arm_lpae_unmap() returns -ENOENT as size_t<br /> -&gt; arm_lpae_unmap_pages() returns it<br /> -&gt; __iommu_unmap() adds it to iova address<br /> -&gt; iommu_pgsize() triggers BUG_ON due to corrupted iova<br /> <br /> This can cause IOVA address overflow in __iommu_unmap() loop and<br /> trigger BUG_ON in iommu_pgsize() from invalid address alignment.<br /> <br /> Fix by returning 0 instead of -ENOENT. The WARN_ON already signals<br /> the error condition, and returning 0 (meaning "nothing unmapped")<br /> is the correct semantic for size_t return type. This matches the<br /> behavior of other io-pgtable implementations (io-pgtable-arm-v7s,<br /> io-pgtable-dart) which return 0 on error conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-sprd-adi: Fix double free in probe error path<br /> <br /> The driver currently uses spi_alloc_host() to allocate the controller<br /> but registers it using devm_spi_register_controller().<br /> <br /> If devm_register_restart_handler() fails, the code jumps to the<br /> put_ctlr label and calls spi_controller_put(). However, since the<br /> controller was registered via a devm function, the device core will<br /> automatically call spi_controller_put() again when the probe fails.<br /> This results in a double-free of the spi_controller structure.<br /> <br /> Fix this by switching to devm_spi_alloc_host() and removing the<br /> manual spi_controller_put() call.