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 /> 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 /> 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 /> 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 /> Octeontx2-af: Add proper checks for fwdata<br /> <br /> firmware populates MAC address, link modes (supported, advertised)<br /> and EEPROM data in shared firmware structure which kernel access<br /> via MAC block(CGX/RPM).<br /> <br /> Accessing fwdata, on boards booted with out MAC block leading to<br /> kernel panics.<br /> <br /> Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 10.460721] Modules linked in:<br /> [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT<br /> [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)<br /> [ 10.479793] Workqueue: events work_for_cpu_fn<br /> [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 10.491124] pc : rvu_sdp_init+0x18/0x114<br /> [ 10.495051] lr : rvu_probe+0xe58/0x1d18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Fix memleak in l2tp_udp_encap_recv().<br /> <br /> syzbot reported memleak of struct l2tp_session, l2tp_tunnel,<br /> sock, etc. [0]<br /> <br /> The cited commit moved down the validation of the protocol<br /> version in l2tp_udp_encap_recv().<br /> <br /> The new place requires an extra error handling to avoid the<br /> memleak.<br /> <br /> Let&amp;#39;s call l2tp_session_put() there.<br /> <br /> [0]:<br /> BUG: memory leak<br /> unreferenced object 0xffff88810a290200 (size 512):<br /> comm "syz.0.17", pid 6086, jiffies 4294944299<br /> hex dump (first 32 bytes):<br /> 7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00 }...............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc babb6a4f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> __do_kmalloc_node mm/slub.c:5656 [inline]<br /> __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778<br /> pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755<br /> __sys_connect_file+0x7a/0xb0 net/socket.c:2089<br /> __sys_connect+0xde/0x110 net/socket.c:2108<br /> __do_sys_connect net/socket.c:2114 [inline]<br /> __se_sys_connect net/socket.c:2111 [inline]<br /> __x64_sys_connect+0x1c/0x30 net/socket.c:2111<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix potential underflow in virtio_transport_get_credit()<br /> <br /> The credit calculation in virtio_transport_get_credit() uses unsigned<br /> arithmetic:<br /> <br /> ret = vvs-&gt;peer_buf_alloc - (vvs-&gt;tx_cnt - vvs-&gt;peer_fwd_cnt);<br /> <br /> If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes<br /> are in flight, the subtraction can underflow and produce a large<br /> positive value, potentially allowing more data to be queued than the<br /> peer can handle.<br /> <br /> Reuse virtio_transport_has_space() which already handles this case and<br /> add a comment to make it clear why we are doing that.<br /> <br /> [Stefano: use virtio_transport_has_space() instead of duplicating the code]<br /> [Stefano: tweak the commit message]