Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: initialize policy rwsem before sysfs publication<br /> <br /> cpufreq_policy_alloc() initializes policy-&gt;rwsem after<br /> kobject_init_and_add() has created the policy sysfs directory and its<br /> default attributes. A sysfs access can therefore reach a policy callback<br /> before the semaphore has been initialized.<br /> <br /> Initialize policy-&gt;rwsem before publishing the policy kobject so sysfs<br /> callbacks always see an initialized semaphore.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: zero-initialize policy cpumask before sysfs publication<br /> <br /> cpufreq_policy_alloc() allocates policy-&gt;cpus with alloc_cpumask_var(),<br /> i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus<br /> masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate<br /> kmalloc_node() allocation, so its bitmap holds whatever the slab allocator<br /> left behind:<br /> <br /> cpufreq_online()<br /> cpufreq_policy_alloc()<br /> alloc_cpumask_var(&amp;policy-&gt;cpus) /* bitmap is uninitialized */<br /> kobject_init_and_add() /* policy%u/ appears in sysfs */<br /> cpufreq_policy_online()<br /> cpumask_copy(policy-&gt;cpus, cpumask_of(cpu)) /* first valid value */<br /> <br /> This leaves a window in which the sysfs attributes are already reachable<br /> while policy-&gt;cpus is still garbage. show()/store() gate on<br /> policy_is_inactive(), i.e. cpumask_empty(policy-&gt;cpus), so a non-zero<br /> bitmap makes them run the attribute callbacks on a policy that is not<br /> initialized yet.<br /> <br /> Fix this by using zalloc_cpumask_var() for policy-&gt;cpus.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bootconfig: Fix integer overflow in initrd size check<br /> <br /> Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd<br /> with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer<br /> arithmetic:<br /> <br /> data = ((void *)hdr) - size;<br /> <br /> to wrap around on 32-bit systems (or when pointer subtraction overflows).<br /> Because data wraps around, the subsequent bounds check:<br /> <br /> if ((unsigned long)data 4.29 GB, an<br /> unbounded 32-bit size can similarly bypass the initrd_start check.<br /> <br /> Fix this by:<br /> 1. Ensuring the initrd is at least large enough to contain the bootconfig<br /> footer and verifying hdr is within the initrd bounds.<br /> 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed<br /> the available space between initrd_start and hdr before performing<br /> pointer subtraction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btrtl: Don&amp;#39;t leak return code when parsing firmware format v2<br /> <br /> When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally<br /> ignores all security headers. However, the implementation simply breaks<br /> from a switch statement and leaks uninitialized return code `rc&amp;#39; (if the<br /> first section is a security one) or the previous section&amp;#39;s `rc&amp;#39;.<br /> <br /> Fix it by really skipping a loop with `continue&amp;#39;. For consistency and<br /> readability, also do the same for the default case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev<br /> <br /> The command and ACL RPMsg endpoints store struct btqcomsmd as their<br /> callback private data. The receive callbacks dereference btq-&gt;hdev<br /> without taking an hci_dev reference.<br /> <br /> The current teardown order frees the hci_dev before destroying the RPMsg<br /> endpoints in both the hci_register_dev() error path and the driver remove<br /> path. If WCNSS delivers data in that window, the endpoint callback can<br /> run with an already freed hci_dev and pass it to the Bluetooth core.<br /> <br /> For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears<br /> the callback under the channel recv_lock. The receive path holds the same<br /> lock while invoking the callback, so destroying the endpoints first both<br /> prevents new callbacks and serializes with any callback already running.<br /> <br /> Destroy the command and ACL endpoints before hci_free_dev(). Keep<br /> hci_unregister_dev() first during remove so the HCI core stops issuing<br /> operations before the transport endpoints are shut down. In the full<br /> registration-error cleanup path, return directly after freeing the hci_dev<br /> to avoid falling through to the partial-construction labels and destroying<br /> the endpoints twice.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sti: initialize IRQ lock before requesting IRQ<br /> <br /> uni_reader_init() registers the shared IRQ before initializing<br /> reader-&gt;irq_lock. A pending interrupt can invoke the handler while the<br /> lock is still uninitialized.<br /> <br /> Initialize the lock before registering the IRQ so the interrupt path<br /> always sees valid lock state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sprd: validate compress buffer sizes against fixed allocations<br /> <br /> sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data<br /> area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but<br /> sprd_platform_compr_copy() derives all copy lengths from the user<br /> controlled runtime-&gt;fragment_size and the write() count, never<br /> comparing them against the physical buffer sizes. The compress core<br /> only checks fragment_size * fragments for an u32 overflow in<br /> snd_compress_check_input(), so a local user can configure a logical<br /> buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the<br /> fixed allocations.<br /> <br /> A fragment_size larger than the 32K IRAM data area makes the stage 0<br /> copy_from_user() overflow past the IRAM allocation, and a buffer_size<br /> larger than the 2M DDR buffer makes the wrapping copy at the end of<br /> sprd_platform_compr_copy() write fully user controlled data past the<br /> buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP<br /> state reaches the copy callback directly.<br /> <br /> Reject parameters that do not fit into the fixed buffers in<br /> set_params(), and fix the advertised max fragment size: 128K never<br /> fitted into the 32K IRAM buffer. The caps values may have been carried over<br /> from the qdsp6 driver, which allocates its buffers according to the<br /> advertised maxima, unlike this driver. With 32K as max fragment size<br /> the advertised limits are self-consistent: 32K * 64 = 2M equals the<br /> DDR buffer size.<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: don&amp;#39;t overconsume buffers when using MSG_TRUNC<br /> <br /> When a recv/recvmsg is issued with MSG_TRUNC and the incoming packet is<br /> larger than the provided buffer, the net layer returns the full length<br /> of the packet rather than the number of bytes actually copied into the<br /> buffer. As a result, io_uring advances more of the provided buffer ring<br /> than was actually filled. Use the actual filled region size to consume<br /> the buffer, but still return the full size to preserve MSG_TRUNC<br /> semantics.<br /> <br /> Take care with multishot, because that seems to already truncate the<br /> consumption based on the available payload size.<br /> <br /> This was reported in https://github.com/axboe/liburing/issues/1619.<br /> <br /> [axboe: fold in size_t unsigned fix]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: end write accounting from -&gt;ki_complete<br /> <br /> Commit b000145e9907 moved both the fsnotify calls and the write<br /> accounting out of the kiocb completion handler and into the<br /> io_req_rw_complete() task_work. However, only the fsnotify part actually<br /> needed to move as it may sleep. Ending the write accounting is just a<br /> percpu_up_read() on the superblock writers sem.<br /> <br /> Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE<br /> protection depend on the ring owner getting to running task_work. But<br /> the task may be blocked in freeze_super(), causing it to never get to<br /> that:<br /> <br /> task io-wq worker<br /> --------------------------------------------------------------<br /> io_write()<br /> io_kiocb_start_write() (takes sb_writers, hidden from<br /> lockdep by __sb_writers_release)<br /> write_iter() -&gt; -EIOCBQUEUED<br /> ioctl(FS_IOC_SHUTDOWN)<br /> bdev_freeze()<br /> freeze_super()<br /> percpu_down_write()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches<br /> <br /> emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to<br /> flush the L2/HDC data cache before fence signalling, but it never<br /> requests a flush of the LSC untyped L1 data cache via the &amp;#39;Untyped<br /> Data-Port Cache Flush Enable&amp;#39; bit in PIPE_CONTROL DWord0[11].<br /> <br /> Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to<br /> also flush/invalidate the untyped L1 cache, but only depending on how<br /> HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling<br /> between HDC Pipeline Flush and the untyped L1 cache flush no longer<br /> holds in practice, regardless of how HDC_CHICKEN0 is programmed, so<br /> relying on it is not safe on newer platforms such as BMG. Mesa&amp;#39;s Vulkan<br /> driver (anv) has been assuming the kernel flushes both caches between<br /> submissions, and hit user-visible corruption in apps such as Llama.cpp<br /> because of this gap; it now works around it by flushing both caches<br /> again from userspace at the end of every command buffer.<br /> <br /> Correctness between submissions on the same queue is userspace&amp;#39;s<br /> responsibility and belongs in Mesa, not the kernel. However, for<br /> security we must ensure stale data can&amp;#39;t leak through the untyped L1<br /> dataport cache once memory is reclaimed or evicted, which requires the<br /> KMD to flush it before releasing memory for reuse.<br /> <br /> Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for<br /> DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline<br /> Flush coupled to the untyped L1 cache flush, so those platforms are<br /> unaffected. Mesa&amp;#39;s own anv driver found that on MTL the HW<br /> disconnected the two independently of how HDC_CHICKEN0 is programmed,<br /> and could not bring the old behavior back even by writing the register<br /> by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don&amp;#39;t prevent L1 untyped<br /> cache flush in 3D mode"). The kernel can&amp;#39;t reliably request the flush<br /> from the CS on MTL either, so restrict the new PIPE_CONTROL bit to<br /> GRAPHICS_VERx100 &gt;= 2000 (Xe2 and later), where it can be relied on.<br /> <br /> Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together<br /> with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on<br /> Xe2 and later, so the L1 data cache is known clean before memory is<br /> released for reuse, without depending on undocumented<br /> platform-specific HDC_CHICKEN0 behavior.<br /> <br /> Bspec: 56551<br /> (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: analogix_dp: fix unchecked bound endpoint name length<br /> <br /> rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree<br /> path into a 32-byte stack buffer. Device tree paths are not limited to<br /> this size, so a sufficiently long path can overflow the buffer.<br /> <br /> Use snprintf() with the destination size to truncate the generated name<br /> and keep the writes within bounds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix memory leak in query_perf_config_list()<br /> <br /> When krealloc() fails, free the original oa_config_ids before returning<br /> to avoid a memory leak.<br /> <br /> (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)