Vulnerabilidades

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

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

*** 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 /> mm/damon/ops-common: putback folios on invalid migrate nid<br /> <br /> damon_pa_migrate() and damos_va_migrate() isolate folios into a local list<br /> and then call damon_migrate_pages(). When target_nid is invalid<br /> (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages()<br /> returns early without putting the folios back to the LRU.<br /> <br /> Callers then discard the list head while those folios remain isolated with<br /> an extra reference taken by folio_isolate_lru(). The pages stay off the<br /> LRU for as long as the mapping exists (anon active+inactive counts drop<br /> while RSS does not), and the leftover references can pin the pages after<br /> the mapping is gone.<br /> <br /> Put the folios back on the invalid-nid path so ignored migration requests<br /> still return them to the LRU.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix NULL pointer dereference in module event cache removal<br /> <br /> A module-only event filter such as ":mod:foo" is cached with a NULL<br /> event_mod-&gt;match when foo has not been loaded. If a later write tries to<br /> remove a specific match from the same module, remove_cache_mod() passes<br /> the NULL cached match to strcmp(), causing a NULL pointer dereference.<br /> <br /> The issue can be reproduced from userspace:<br /> <br /> echo &amp;#39;:mod:trace_events_kunit_missing&amp;#39; &gt; /sys/kernel/tracing/set_event<br /> echo &amp;#39;!foo_bar:mod:trace_events_kunit_missing&amp;#39; &gt;&gt; /sys/kernel/tracing/set_event<br /> <br /> The second write must be a concatenation ("&gt;&gt;") to not include O_TRUNC as<br /> that would cause ftrace_clear_events() to clear the cached modules lines.<br /> <br /> The crash was reproduced on x86_64 QEMU while KUnit workers contended on<br /> the event tracing path:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:strcmp+0x10/0x30<br /> Call Trace:<br /> __ftrace_set_clr_event_nolock+0x373/0x4a0<br /> ftrace_set_clr_event+0xf0/0x180<br /> ftrace_event_write+0xdf/0x110<br /> vfs_write+0xf6/0x440<br /> ksys_write+0x68/0xe0<br /> do_syscall_64+0xf9/0x540<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Check event_mod-&gt;match before comparing it, consistent with the existing<br /> NULL checks for the cached system and event fields. The mismatched removal<br /> continues to return -EINVAL; a broad cached module filter is removed with<br /> "!:mod:".