Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Remove buffer from list prior to unmap operation<br /> <br /> fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is<br /> getting removed from the list after it is unmapped from DSP. This can<br /> create potential race conditions if multiple threads invoke unmap<br /> concurrently, where one thread may remove the entry from the list while<br /> another thread&amp;#39;s unmap operation is still ongoing.<br /> <br /> Fix this by removing the buffer entry from the list before calling the<br /> unmap operation. If the unmap fails, the entry is re-added to the list<br /> so that userspace can retry the unmap, or alternatively, the buffer<br /> will be cleaned up during device release when the DSP process is torn<br /> down and all DSP-side mappings are freed along with remaining buffers<br /> in the list.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: validate monitor transmit frame lengths<br /> <br /> rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and<br /> then reads the 802.11 frame control field without checking that a base<br /> 802.11 header remains.<br /> <br /> The data path also pulls the calculated 802.11, QoS and SNAP header<br /> span before confirming that the skb contains it. A truncated frame can<br /> therefore cause out-of-bounds reads or leave insufficient data for the<br /> Ethernet address writes.<br /> <br /> Reject frames that do not contain the base 802.11 header and data<br /> frames that do not contain their complete calculated header span.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix missing shared-key auth challenge length check<br /> <br /> The WEP shared-key authentication handler uses the challenge-text<br /> element&amp;#39;s attacker-controlled length without checking it against the<br /> fixed 128-byte chg_txt buffer.<br /> <br /> In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used<br /> to perform memcpy() into the 128-byte pmlmeinfo-&gt;chg_txt, so a<br /> malicious AP sending a malformed WLAN_EID_CHALLENGE element can<br /> overflow/underfill chg_txt by up to 127 bytes. It is reachable over the<br /> air, before association, during shared-key authentication. In the case<br /> of an overflow, the driver can write out of bounds. In the case of an<br /> underfill, the driver can echo stale buffer memory.<br /> <br /> The challenge text is defined to be exactly 128 octets, which is<br /> already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the<br /> element to be exactly that length before use.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()<br /> <br /> rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific<br /> information element without checking that the element is long enough,<br /> causing an out-of-bounds read for a short trailing IE.<br /> <br /> The function locates a vendor-specific IE (EID 221) with rtw_get_ie()<br /> and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte<br /> version word at pbuf + 6. Those accesses require the IE body to be at<br /> least 6 bytes, but rtw_get_ie() only guarantees that the element fits<br /> within the buffer; it does not enforce a minimum body length. A<br /> vendor-specific IE whose length byte is 0 to 5, placed at the end of<br /> the buffer, therefore makes these reads run past the end of the IE and<br /> past the end of the buffer itself.<br /> <br /> The buffer holds information elements taken from received management<br /> frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which<br /> is kmemdup&amp;#39;d to its exact length, so the read can run off the end of<br /> the allocation.<br /> <br /> The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and<br /> rtw_get_wps_ie() in this file already reject too-short vendor-specific<br /> IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in<br /> line with them, and needs a minimum of 6 rather than 4 bytes because<br /> of the version word. Add the missing length check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ<br /> <br /> The RS485 trigger hrtimers are embedded in the devm-managed port and can<br /> fire after it is freed. The IRQ handler can arm a timer, so free the IRQ<br /> first and then cancel both timers.<br /> <br /> Complete the RS485 stop without arming a timer, and cancel the timers<br /> in remove() for the suspend-then-unbind path, where shutdown is not<br /> called.<br /> <br /> This issue was found by an in-house static analysis tool.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx<br /> <br /> The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout<br /> interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT<br /> (0x0c) but LSR.DR is clear. A character timeout is only cleared by<br /> reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is<br /> set, so nothing ever clears the condition. The interrupt is<br /> level-triggered and re-fires immediately, so on a single-core ARM926<br /> the resulting interrupt storm livelocks the CPU.<br /> <br /> It is reproducible when userspace repeatedly opens the front-panel port<br /> (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and<br /> the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping<br /> the soft-lockup detector in serial8250_handle_irq_locked().<br /> <br /> LPC32xx has no dedicated 8250 glue driver, it&amp;#39;s driven by the generic<br /> 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up<br /> in of_platform_serial_setup() the same way fsl8250_handle_irq is<br /> installed. The handler follows dw8250_handle_irq(): on an RX timeout<br /> with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR<br /> read to clear the condition, then calls serial8250_handle_irq_locked().<br /> No real received data is ever discarded, and it is a no-op on healthy<br /> UARTs which never report a timeout with DR clear.<br /> <br /> This is the same class of bug already worked around in other 8250 drivers;<br /> see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt")<br /> which reports the identical iir=0xcc/lsr=0x60. See also<br /> UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in WMM_param_handler()<br /> <br /> WMM_param_handler() copies a fixed-size WMM parameter element out of a<br /> received information element without checking that the element is long<br /> enough, causing an out-of-bounds read for a short WMM IE.<br /> <br /> The handler reads sizeof(struct WMM_para_element) (18) bytes at<br /> pIE-&gt;data + 6, so it requires pIE-&gt;length to be at least 24<br /> (WLAN_WMM_LEN), but it never validates the length. Two of its three<br /> callers reach it after matching only the WMM OUI: OnAssocRsp() in<br /> rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a<br /> 4-byte OUI, before calling the handler. A vendor-specific IE carrying<br /> the WMM OUI but a length between 6 and 23, placed in an association<br /> response or in the IE blob handed to join_cmd_hdl(), passes the OUI<br /> check and then makes the memcmp() and memcpy() at pIE-&gt;data + 6 read<br /> past the end of the element. OnAssocRsp() parses a frame received from<br /> the AP, so this is reachable from a remote peer.<br /> <br /> The remaining caller in rtw_wlan_util.c already guards the handler with<br /> "pIE-&gt;length == WLAN_WMM_LEN". Move the equivalent check into the<br /> handler itself so every caller is covered; the sibling IE handlers in<br /> the same parsing loop (HT_caps_handler(), HT_info_handler(),<br /> ERP_IE_handler()) likewise bound their accesses by pIE-&gt;length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_dma: Clear stale RX state on shutdown<br /> <br /> serial8250_release_dma() terminates RX DMA and releases the channel, but<br /> leaves rx_running set. If the port is closed while an RX transfer is<br /> active, the stale state remains while rxchan is NULL until the channel is<br /> requested again on the next open.<br /> <br /> The DesignWare BUSY workaround added by commit a7b9ce39fbe4<br /> ("serial: 8250_dw: Ensure BUSY is deasserted") calls<br /> serial8250_rx_dma_flush() from the LCR write path during startup. This<br /> happens before serial8250_request_dma() obtains a new RX channel. On<br /> reopen, the stale rx_running state therefore makes the flush path pass a<br /> NULL channel to dmaengine_pause(), causing a kernel Oops.<br /> <br /> Clear rx_running after terminating RX DMA, matching the TX cleanup. Also<br /> make the flush helper return if the DMA object or RX channel is not<br /> available so startup and teardown paths cannot pass a NULL channel to the<br /> DMAengine API.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: bound the hwdep mmap fault offset<br /> <br /> snd_us428ctls_vm_fault() turns the faulting page offset into a kernel<br /> address with no bound of any kind:<br /> <br /> offset = vmf-&gt;pgoff page = page;<br /> <br /> return 0;<br /> <br /> snd_us428ctls_mmap() checks only the length of the mapping, never the<br /> offset, and us428ctls_sharedmem is a single page from<br /> alloc_pages_exact(). For a character device file_mmap_size_max()<br /> returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page<br /> offset above zero resolves to a struct page outside the object, and the<br /> handler installs it into the caller&amp;#39;s address space read-write; the vma<br /> is not marked read-only.<br /> <br /> The caller picks the page frame with a single mmap() argument and gets<br /> read-write access to a page of kernel memory it does not own; an offset<br /> that lands in an unpopulated vmemmap region oopses instead.<br /> <br /> A process that can open the hwdep node of an attached US-X2Y reaches<br /> this after loading the FPGA image through the same node; no capability<br /> check is involved.<br /> <br /> On 7.2.0-rc5 (arm64), mmap() with a large offset:<br /> <br /> Unable to handle kernel paging request at virtual address fffffdffc45d5ac8<br /> pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]<br /> Call trace:<br /> snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]<br /> __do_fault<br /> __handle_mm_fault<br /> handle_mm_fault<br /> el0_da<br /> <br /> Reject any offset outside the shared region. The pcm hwdep handler in<br /> usx2yhwdeppcm.c computes its address the same way and needs the same<br /> bound.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Serialize the scheduler timeout handlers<br /> <br /> V3D exposes several independent hardware queues (BIN, RENDER, TFU and<br /> CSD) but has only a single, global reset. A timeout on any one queue<br /> therefore has to stop, reset and restart the schedulers of every other<br /> queue as well. That makes concurrent timeout handlers unsafe.<br /> <br /> `reset_lock` was never able to make them safe, as a driver-side lock can<br /> only cover the driver&amp;#39;s &amp;drm_sched_backend_ops.timedout_job callback.<br /> The scheduler handles the timed out job and its pending list around that<br /> callback, outside of the driver&amp;#39;s control, so a global reset triggered<br /> by one queue can still interfere with another queue that is in the<br /> middle of handling a timeout of its own.<br /> <br /> Consequently, if a reset happens in the CSD queue while a CL-intensive<br /> application is running, the global reset stops and restarts the CL<br /> queue&amp;#39;s scheduler while that queue is handling a timeout of its own. As<br /> drm_sched_stop() and drm_sched_start() subtract and add the credits of<br /> every job sitting on the pending list of the scheduler they are called<br /> on, and as the CL queue&amp;#39;s handler concurrently takes its job off that<br /> same list and puts it back, the stop and the start no longer see the<br /> same set of jobs. The CL queue is left with more credits in flight than<br /> its limit:<br /> <br /> [ 327.302739] ------------[ cut here ]------------<br /> [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched]<br /> [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT<br /> [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)<br /> [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]<br /> [ 327.302984] Call trace:<br /> [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P)<br /> [ 327.302997] process_scheduled_works+0x180/0x3d0<br /> [ 327.303010] worker_thread+0x268/0x3e8<br /> [ 327.303016] kthread+0x140/0x250<br /> [ 327.303022] ret_from_fork+0x10/0x20<br /> [ 327.303031] ---[ end trace 0000000000000000 ]---<br /> <br /> From that point on, the credit count of the CL queue is broken, causing<br /> a complete GPU hang and UI freeze.<br /> <br /> The DRM scheduler already provides a mechanism to serialize the timeout<br /> handlers of different schedulers: an ordered workqueue passed as<br /> drm_sched_init()&amp;#39;s @timeout_wq parameter. By default, each scheduler<br /> queues its timeout work on the system workqueue, which runs the handlers<br /> concurrently. Give all of the queues a shared ordered workqueue instead,<br /> as recommended by the DRM scheduler documentation for hardware that has<br /> distinct queues but resets globally.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: FCP: fix OOB write in fcp_meter_ctl_get()<br /> <br /> fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size<br /> by the driver&amp;#39;s own limit of 255<br /> <br /> if (map.map_size 255 ||<br /> map.meter_slots 255)<br /> return -EINVAL;<br /> <br /> and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where<br /> it is stored as elem-&gt;channels.<br /> <br /> Every control read writes into struct snd_ctl_elem_value, whose integer<br /> array is declared long value[128], so the limit is 128, not 255.<br /> fcp_meter_ctl_get() stores one 64-bit word per channel into that array<br /> with no bound of its own:<br /> <br /> for (i = 0; i channels; i++) {<br /> int idx = private-&gt;meter_level_map[i];<br /> int value = idx value.integer.value[i] = value;<br /> }<br /> <br /> snd_ctl_elem_read_user() serves that object from<br /> memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of<br /> kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so<br /> element i is written at byte 72 + 8 * i and element 144 already lands<br /> past the allocation. At map_size 255 the last store ends at byte 2112,<br /> 888 bytes past the object and 64 bytes into the adjacent slab object.<br /> The stored words come from the device and meter_level_map[] selects<br /> which word lands in which slot, so extent and contents are both<br /> controlled.<br /> <br /> The core does not catch this. snd_ctl_check_elem_info() is reached only<br /> from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under<br /> CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a<br /> compile-time true. __snd_ctl_add_replace() validates kcontrol-&gt;count and<br /> never inspects elem-&gt;channels.<br /> <br /> Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives<br /> the hwdep descriptor that created it, so the out-of-bounds stores are<br /> issued by any process able to read controls on /dev/snd/controlC0.<br /> <br /> KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:<br /> <br /> BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get<br /> Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185<br /> __asan_store8<br /> fcp_meter_ctl_get<br /> snd_ctl_elem_read<br /> snd_ctl_ioctl<br /> Allocated by task 185:<br /> memdup_user<br /> snd_ctl_ioctl<br /> The buggy address is located 0 bytes to the right of<br /> allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)<br /> <br /> Bound the map size by the ABI limit rather than by 255, and bound the<br /> store loop at the sink so it cannot run past the value array whatever<br /> elem-&gt;channels holds.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: take fl-&gt;lock when moving mmaps on interrupted invoke<br /> <br /> When an invoke is interrupted by a signal,<br /> wait_for_completion_interruptible() returns -ERESTARTSYS and<br /> fastrpc_internal_invoke() moves every buffer from fl-&gt;mmaps onto<br /> cctx-&gt;invoke_interrupted_mmaps. This list_del()/list_add_tail() walk<br /> runs without holding fl-&gt;lock, the lock that serialises fl-&gt;mmaps in<br /> fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else.<br /> <br /> Take fl-&gt;lock around the move, matching every other fl-&gt;mmaps accessor.