Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ<br /> <br /> This adds a check for encryption key size upon receiving<br /> L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which<br /> expects L2CAP_CR_LE_BAD_KEY_SIZE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx23885: Add missing unmap in snd_cx23885_hw_params()<br /> <br /> In error path, add cx23885_alsa_dma_unmap() to release the<br /> resource acquired by cx23885_alsa_dma_map().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()<br /> <br /> Do not crash when a report has no fields.<br /> <br /> Fake USB gadgets can send their own HID report descriptors and can define report<br /> structures without valid fields. This can be used to crash the kernel over USB.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umem: Fix double dma_buf_unpin in failure path<br /> <br /> In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to<br /> ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf<br /> is immediately unpinned but the umem_dmabuf-&gt;pinned flag is still<br /> set. Then, when ib_umem_release() is called, it calls<br /> ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.<br /> <br /> Fix this by removing the immediate unpin upon failure and just let<br /> the ib_umem_release/revoke path handle it. This also ensures the<br /> proper unmap-unpin unwind ordering if the dmabuf_map_pages call<br /> happened to fail due to dma_resv_wait_timeout (and therefore has<br /> a non-NULL umem_dmabuf-&gt;sgt).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix circular locking dependency in run_unpack_ex<br /> <br /> Syzbot reported a circular locking dependency between wnd-&gt;rw_lock<br /> (sbi-&gt;used.bitmap) and ni-&gt;file.run_lock.<br /> <br /> The deadlock scenario:<br /> 1. ntfs_extend_mft() takes ni-&gt;file.run_lock then wnd-&gt;rw_lock.<br /> 2. run_unpack_ex() takes wnd-&gt;rw_lock then tries to acquire<br /> ni-&gt;file.run_lock inside ntfs_refresh_zone().<br /> <br /> This creates an AB-BA deadlock.<br /> <br /> Fix this by using down_read_trylock() instead of down_read() when<br /> acquiring run_lock in run_unpack_ex(). If the lock is contended,<br /> skip ntfs_refresh_zone() - the MFT zone will be refreshed on the<br /> next MFT operation. This breaks the circular dependency since we<br /> never block waiting for run_lock while holding wnd-&gt;rw_lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: mixer: oss: Add card disconnect checkpoints<br /> <br /> ALSA OSS mixer layer calls the kcontrol ops rather individually, and<br /> pending calls might be not always caught at disconnecting the device.<br /> <br /> For avoiding the potential UAF scenarios, add sanity checks of the<br /> card disconnection at each entry point of OSS mixer accesses. The<br /> rwsem is taken just before that check, hence the rest context should<br /> be covered by that properly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: validate length in dlm_search_rsb_tree<br /> <br /> The len parameter in dlm_dump_rsb_name() is not validated and comes<br /> from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can<br /> cause out-of-bounds write in dlm_search_rsb_tree().<br /> <br /> Add length validation to prevent potential buffer overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: ram_core: fix incorrect success return when vmap() fails<br /> <br /> In persistent_ram_vmap(), vmap() may return NULL on failure.<br /> <br /> If offset is non-zero, adding offset_in_page(start) causes the function<br /> to return a non-NULL pointer even though the mapping failed.<br /> persistent_ram_buffer_map() therefore incorrectly returns success.<br /> <br /> Subsequent access to prz-&gt;buffer may dereference an invalid address<br /> and cause crashes.<br /> <br /> Add proper NULL checking for vmap() failures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: verify the previous kernel&amp;#39;s IMA buffer lies in addressable RAM<br /> <br /> Patch series "Address page fault in ima_restore_measurement_list()", v3.<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=" we observe a pafe fault that happens.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) not-present page<br /> <br /> This happens on x86_64 only, as this is already fixed in aarch64 in<br /> commit: cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds")<br /> <br /> <br /> This patch (of 3):<br /> <br /> When the second-stage kernel is booted with a limiting command line (e.g. <br /> "mem="), the IMA measurement buffer handed over from the previous<br /> kernel may fall outside the addressable RAM of the new kernel. Accessing<br /> such a buffer can fault during early restore.<br /> <br /> Introduce a small generic helper, ima_validate_range(), which verifies<br /> that a physical [start, end] range for the previous-kernel IMA buffer lies<br /> within addressable memory:<br /> - On x86, use pfn_range_is_mapped().<br /> - On OF based architectures, use page_is_ram().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: processor: Update cpuidle driver check in __acpi_processor_start()<br /> <br /> Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle<br /> driver registration") moved the ACPI idle driver registration to<br /> acpi_processor_driver_init() and acpi_processor_power_init() does<br /> not register an idle driver any more.<br /> <br /> Accordingly, the cpuidle driver check in __acpi_processor_start() needs<br /> to be updated to avoid calling acpi_processor_power_init() without a<br /> cpuidle driver, in which case the registration of the cpuidle device<br /> in that function would lead to a NULL pointer dereference in<br /> __cpuidle_register_device().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: check return value of con2fb_acquire_newinfo()<br /> <br /> If fbcon_open() fails when called from con2fb_acquire_newinfo() then<br /> info-&gt;fbcon_par pointer remains NULL which is later dereferenced.<br /> <br /> Add check for return value of the function con2fb_acquire_newinfo() to<br /> avoid it.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix user_ref race between scrub and refill paths<br /> <br /> The io_zcrx_put_niov_uref() function uses a non-atomic<br /> check-then-decrement pattern (atomic_read followed by separate<br /> atomic_dec) to manipulate user_refs. This is serialized against other<br /> callers by rq_lock, but io_zcrx_scrub() modifies the same counter with<br /> atomic_xchg() WITHOUT holding rq_lock.<br /> <br /> On SMP systems, the following race exists:<br /> <br /> CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock)<br /> put_niov_uref:<br /> atomic_read(uref) - 1<br /> // window opens<br /> atomic_xchg(uref, 0) - 1<br /> return_niov_freelist(niov) [PUSH #1]<br /> // window closes<br /> atomic_dec(uref) - wraps to -1<br /> returns true<br /> return_niov(niov)<br /> return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]<br /> <br /> The same niov is pushed to the freelist twice, causing free_count to<br /> exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds<br /> write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent<br /> slab object.<br /> <br /> Fix this by replacing the non-atomic read-then-dec in<br /> io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically<br /> tests and decrements user_refs. This makes the operation safe against<br /> concurrent atomic_xchg from scrub without requiring scrub to acquire<br /> rq_lock.<br /> <br /> [pavel: removed a warning and a comment]