Vulnerabilities

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 /> 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 /> wifi: rsi: Fix memory corruption due to not set vif driver data size<br /> <br /> The struct ieee80211_vif contains trailing space for vif driver data,<br /> when struct ieee80211_vif is allocated, the total memory size that is<br /> allocated is sizeof(struct ieee80211_vif) + size of vif driver data.<br /> The size of vif driver data is set by each WiFi driver as needed.<br /> <br /> The RSI911x driver does not set vif driver data size, no trailing space<br /> for vif driver data is therefore allocated past struct ieee80211_vif .<br /> The RSI911x driver does however use the vif driver data to store its<br /> vif driver data structure "struct vif_priv". An access to vif-&gt;drv_priv<br /> leads to access out of struct ieee80211_vif bounds and corruption of<br /> some memory.<br /> <br /> In case of the failure observed locally, rsi_mac80211_add_interface()<br /> would write struct vif_priv *vif_info = (struct vif_priv *)vif-&gt;drv_priv;<br /> vif_info-&gt;vap_id = vap_idx. This write corrupts struct fq_tin member<br /> struct list_head new_flows . The flow = list_first_entry(head, struct<br /> fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus<br /> address, which when accessed causes a crash.<br /> <br /> The trigger is very simple, boot the machine with init=/bin/sh , mount<br /> devtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1",<br /> "ip link set wlan0 down" and the crash occurs.<br /> <br /> Fix this by setting the correct size of vif driver data, which is the<br /> size of "struct vif_priv", so that memory is allocated and the driver<br /> can store its driver data in it, instead of corrupting memory around<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Enforce that teql can only be used as root qdisc<br /> <br /> Design intent of teql is that it is only supposed to be used as root qdisc.<br /> We need to check for that constraint.<br /> <br /> Although not important, I will describe the scenario that unearthed this<br /> issue for the curious.<br /> <br /> GangMin Kim managed to concot a scenario as follows:<br /> <br /> ROOT qdisc 1:0 (QFQ)<br /> ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s<br /> └── class 1:2 (weight=1, lmax=1514) teql<br /> <br /> GangMin sends a packet which is enqueued to 1:1 (netem).<br /> Any invocation of dequeue by QFQ from this class will not return a packet<br /> until after 6.4s. In the meantime, a second packet is sent and it lands on<br /> 1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.<br /> Main issue is that teql only updates the parent visible qlen (sch-&gt;q.qlen)<br /> at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s<br /> peek always returns NULL), dequeue will never be called and thus the qlen<br /> will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,<br /> the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s<br /> qlen was not incremented, qfq fails to deactivate the class, but still<br /> frees its pointers from the aggregate. So when the first packet is<br /> rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is<br /> accessed causing GangMin&amp;#39;s causing a UAF.

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