Vulnerabilidades

*** 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 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 /> 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 /> 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 /> 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: us144mkii: re-anchor capture URBs on resubmission<br /> <br /> capture_urb_complete() resubmits each capture URB without anchoring it:<br /> <br /> usb_get_urb(urb);<br /> ret = usb_submit_urb(urb, GFP_ATOMIC);<br /> <br /> Anchoring is a property of a submission, not of the URB. The giveback<br /> path calls usb_unanchor_urb() before urb-&gt;complete(), so an URB<br /> resubmitted from its own completion handler is off the anchor. The<br /> capture URBs are anchored once, at stream start, so from the first<br /> completion onward tascam-&gt;capture_anchor is empty.<br /> <br /> tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the<br /> stop-work path all call usb_kill_anchored_urbs(&amp;tascam-&gt;capture_anchor)<br /> to reap the capture URBs before anything is freed. With the anchor empty<br /> those calls return immediately and the URBs stay queued on the host<br /> controller.<br /> <br /> tascam_free_urbs() then returns the capture transfer buffers with<br /> usb_free_coherent(), and snd_card_free() releases the snd_card<br /> allocation that embeds tascam (card-&gt;private_data). The controller<br /> completes the queued URBs afterwards, writing device-supplied data into<br /> the freed transfer buffer, and capture_urb_complete() dereferences the<br /> freed driver object.<br /> <br /> KASAN on 7.2.0-rc5 (arm64):<br /> <br /> BUG: KASAN: slab-use-after-free in dummy_timer<br /> Write of size 512 at addr ffff000015b62000<br /> __asan_memcpy<br /> dummy_timer<br /> hrtimer_run_softirq<br /> Allocated by task 64:<br /> usb_alloc_coherent<br /> tascam_alloc_urbs<br /> tascam_probe<br /> Freed by task 170:<br /> usb_free_coherent<br /> tascam_free_urbs<br /> tascam_disconnect<br /> usb_unbind_interface<br /> <br /> BUG: KASAN: slab-use-after-free in capture_urb_complete<br /> Read of size 4 at addr ffff0000170ee878<br /> Freed by task 170:<br /> release_card_device<br /> snd_card_free<br /> tascam_disconnect<br /> <br /> Restore the usb_anchor_urb() between the reference count bump and the<br /> resubmission. That also makes the handler&amp;#39;s usb_unanchor_urb() failure<br /> arm meaningful again and restores usb_kill_anchored_urbs() as a barrier<br /> on the disconnect, suspend and stop-work paths.<br /> <br /> The anchoring was removed on the premise that the URB is already anchored<br /> from the initial submission, which does not hold once the first giveback<br /> has run.<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 /> 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 /> ALSA: usb: Fix UAF at delayed release of MIDI2 EPs<br /> <br /> The recent fix for UAF in ump_to_endpoint() caused another UAF because<br /> it tries to dereference the UMP endpoint object, but this might be<br /> executed at a delayed context where the endpoint has been already<br /> released.<br /> <br /> Add private_free to clear the associated data for avoiding the further<br /> dereference for delayed releases.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/damon/mtier: error out for zero quota goal target values<br /> <br /> Patch series "mm/damon: avoid division by zero from damos_quota_score()".<br /> <br /> DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division<br /> by zero in damos_quota_score(). Avoid it by adding parameters validation<br /> checks.<br /> <br /> <br /> This patch (of 2):<br /> <br /> damos_quota_score() can trigger division by zero if the target_value is<br /> zero. DAMON_SAMPLE_MTIER lets users set the target_value via<br /> node0_mem_{used,free}_bp parameters. It doesn&amp;#39;t guard zero value case,<br /> though. As a result, users can trigger division by zero. Fix the issue<br /> by returning an error when the user tries to start DAMON with zero<br /> node0_mem_{used,free}_bp parameter values.<br /> <br /> DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite<br /> bad. Also the zero node0_mem_free_bp parameter might look like a<br /> reasonable setup to some users. Hence, the issue might really happen in<br /> the real world.<br /> <br /> One reliable way to reproduce the issue is like below:<br /> <br /> # cd /sys/module/damon_sample_mtier/parameters<br /> # echo 4096 &gt; node0_start_addr<br /> # echo 8192 &gt; node0_end_addr<br /> # echo 8192 &gt; node1_start_addr<br /> # echo 81920 &gt; node1_end_addr<br /> # echo 0 &gt; node0_mem_free_bp<br /> # echo Y &gt; enabled<br /> # dmesg -w<br /> [...]<br /> [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI<br /> [...]<br /> [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480<br /> [...]<br /> <br /> This issue was discovered [1] by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: error out for &gt;10000 active_mem_bp<br /> <br /> damos_quota_score() can trigger division by zero if the target value is<br /> zero. DAMON_LRU_SORT lets users set the target value for the hot memory<br /> scheme via active_mem_bp parameter. It avoids setting it as the target<br /> value if the parameter value is zero. However, it also sets the cold<br /> memory scheme with a target value that is calculated as &amp;#39;10000 -<br /> active_mem_bp + 2&amp;#39;. Hence, if a user sets active_mem_bp 10002, the cold<br /> memory scheme&amp;#39;s quota goal target value can be zero. As a result,<br /> division by zero can be triggered. Fix by returning an error when the<br /> user tries to start DAMON with &gt;10000 active_mem_bp parameter value.<br /> <br /> It makes no sense to set active_mem_bp with 10002. It also requires<br /> module parameters write permission to reproduce the issue. That said, the<br /> consequence is quite bad.<br /> <br /> One reliable way to reproduce the issue is like below:<br /> <br /> # cd /sys/module/damon_lru_sort/parameters<br /> # echo 1000 &gt; wmarks_high<br /> # echo 995 &gt; wmarks_mid<br /> # echo 0 &gt; wmarks_low<br /> # echo 10002 &gt; active_mem_bp<br /> # echo Y &gt; enabled<br /> # dmesg -w<br /> [...]<br /> [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI<br /> [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480<br /> <br /> This issue was discovered [1] by Sashiko.