Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mdiobus: Fix potential out-of-bounds read/write access<br /> <br /> When using publicly available tools like &amp;#39;mdio-tools&amp;#39; to read/write data<br /> from/to network interface and its PHY via mdiobus, there is no verification of<br /> parameters passed to the ioctl and it accepts any mdio address.<br /> Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,<br /> but it is possible to pass higher value than that via ioctl.<br /> While read/write operation should generally fail in this case,<br /> mdiobus provides stats array, where wrong address may allow out-of-bounds<br /> read/write.<br /> <br /> Fix that by adding address verification before read/write operation.<br /> While this excludes this access from any statistics, it improves security of<br /> read/write operation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix TOCTOU issue in sk_is_readable()<br /> <br /> sk-&gt;sk_prot-&gt;sock_is_readable is a valid function pointer when sk resides<br /> in a sockmap. After the last sk_psock_put() (which usually happens when<br /> socket is removed from sockmap), sk-&gt;sk_prot gets restored and<br /> sk-&gt;sk_prot-&gt;sock_is_readable becomes NULL.<br /> <br /> This makes sk_is_readable() racy, if the value of sk-&gt;sk_prot is reloaded<br /> after the initial check. Which in turn may lead to a null pointer<br /> dereference.<br /> <br /> Ensure the function pointer does not turn NULL after the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> espintcp: remove encap socket caching to avoid reference leak<br /> <br /> The current scheme for caching the encap socket can lead to reference<br /> leaks when we try to delete the netns.<br /> <br /> The reference chain is: xfrm_state -&gt; enacp_sk -&gt; netns<br /> <br /> Since the encap socket is a userspace socket, it holds a reference on<br /> the netns. If we delete the espintcp state (through flush or<br /> individual delete) before removing the netns, the reference on the<br /> socket is dropped and the netns is correctly deleted. Otherwise, the<br /> netns may not be reachable anymore (if all processes within the ns<br /> have terminated), so we cannot delete the xfrm state to drop its<br /> reference on the socket.<br /> <br /> This patch results in a small (~2% in my tests) performance<br /> regression.<br /> <br /> A GC-type mechanism could be added for the socket cache, to clear<br /> references if the state hasn&amp;#39;t been used "recently", but it&amp;#39;s a lot<br /> more complex than just not caching the socket.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Don&amp;#39;t treat wb connector as physical in create_validate_stream_for_sink<br /> <br /> Don&amp;#39;t try to operate on a drm_wb_connector as an amdgpu_dm_connector.<br /> While dereferencing aconnector-&gt;base will "work" it&amp;#39;s wrong and<br /> might lead to unknown bad things. Just... don&amp;#39;t.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken<br /> <br /> A SCO connection without the proper voice_setting can cause<br /> the controller to lock up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/iopl: Cure TIF_IO_BITMAP inconsistencies<br /> <br /> io_bitmap_exit() is invoked from exit_thread() when a task exists or<br /> when a fork fails. In the latter case the exit_thread() cleans up<br /> resources which were allocated during fork().<br /> <br /> io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up<br /> in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the<br /> current task. If current has TIF_IO_BITMAP set, but no bitmap installed,<br /> tss_update_io_bitmap() crashes with a NULL pointer dereference.<br /> <br /> There are two issues, which lead to that problem:<br /> <br /> 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when<br /> the task, which is cleaned up, is not the current task. That&amp;#39;s a<br /> clear indicator for a cleanup after a failed fork().<br /> <br /> 2) A task should not have TIF_IO_BITMAP set and neither a bitmap<br /> installed nor IOPL emulation level 3 activated.<br /> <br /> This happens when a kernel thread is created in the context of<br /> a user space thread, which has TIF_IO_BITMAP set as the thread<br /> flags are copied and the IO bitmap pointer is cleared.<br /> <br /> Other than in the failed fork() case this has no impact because<br /> kernel threads including IO workers never return to user space and<br /> therefore never invoke tss_update_io_bitmap().<br /> <br /> Cure this by adding the missing cleanups and checks:<br /> <br /> 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if<br /> the to be cleaned up task is not the current task.<br /> <br /> 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user<br /> space forks it is set later, when the IO bitmap is inherited in<br /> io_bitmap_share().<br /> <br /> For paranoia sake, add a warning into tss_update_io_bitmap() to catch<br /> the case, when that code is invoked with inconsistent state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set()<br /> <br /> Enlarge the critical section in ring_buffer_subbuf_order_set() to<br /> ensure that error handling takes place with per-buffer mutex held,<br /> thus preventing list corruption and other concurrency-related issues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify<br /> <br /> During our test, it is found that a warning can be trigger in try_grab_folio<br /> as follow:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)<br /> RIP: 0010:try_grab_folio+0x106/0x130<br /> Call Trace:<br /> <br /> follow_huge_pmd+0x240/0x8e0<br /> follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0<br /> follow_pud_mask.constprop.0.isra.0+0x14a/0x170<br /> follow_page_mask+0x1c2/0x1f0<br /> __get_user_pages+0x176/0x950<br /> __gup_longterm_locked+0x15b/0x1060<br /> ? gup_fast+0x120/0x1f0<br /> gup_fast_fallback+0x17e/0x230<br /> get_user_pages_fast+0x5f/0x80<br /> vmci_host_unlocked_ioctl+0x21c/0xf80<br /> RIP: 0033:0x54d2cd<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Digging into the source, context-&gt;notify_page may init by get_user_pages_fast<br /> and can be seen in vmci_ctx_unset_notify which will try to put_page. However<br /> get_user_pages_fast is not finished here and lead to following<br /> try_grab_folio warning. The race condition is shown as follow:<br /> <br /> cpu0 cpu1<br /> vmci_host_do_set_notify<br /> vmci_host_setup_notify<br /> get_user_pages_fast(uva, 1, FOLL_WRITE, &amp;context-&gt;notify_page);<br /> lockless_pages_from_mm<br /> gup_pgd_range<br /> gup_huge_pmd // update &amp;context-&gt;notify_page<br /> vmci_host_do_set_notify<br /> vmci_ctx_unset_notify<br /> notify_page = context-&gt;notify_page;<br /> if (notify_page)<br /> put_page(notify_page); // page is freed<br /> __gup_longterm_locked<br /> __get_user_pages<br /> follow_trans_huge_pmd<br /> try_grab_folio // warn here<br /> <br /> To slove this, use local variable page to make notify_page can be seen<br /> after finish get_user_pages_fast.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()<br /> <br /> Update struct hid_descriptor to better reflect the mandatory and<br /> optional parts of the HID Descriptor as per USB HID 1.11 specification.<br /> Note: the kernel currently does not parse any optional HID class<br /> descriptors, only the mandatory report descriptor.<br /> <br /> Update all references to member element desc[0] to rpt_desc.<br /> <br /> Add test to verify bLength and bNumDescriptors values are valid.<br /> <br /> Replace the for loop with direct access to the mandatory HID class<br /> descriptor member for the report descriptor. This eliminates the<br /> possibility of getting an out-of-bounds fault.<br /> <br /> Add a warning message if the HID descriptor contains any unsupported<br /> optional HID class descriptors.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Kill timer properly at removal<br /> <br /> The USB-audio MIDI code initializes the timer, but in a rare case, the<br /> driver might be freed without the disconnect call. This leaves the<br /> timer in an active state while the assigned object is released via<br /> snd_usbmidi_free(), which ends up with a kernel warning when the debug<br /> configuration is enabled, as spotted by fuzzer.<br /> <br /> For avoiding the problem, put timer_shutdown_sync() at<br /> snd_usbmidi_free(), so that the timer can be killed properly.<br /> While we&amp;#39;re at it, replace the existing timer_delete_sync() at the<br /> disconnect callback with timer_shutdown_sync(), too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: don&amp;#39;t warn when if there is a FW error<br /> <br /> iwl_trans_reclaim is warning if it is called when the FW is not alive.<br /> But if it is called when there is a pending restart, i.e. after a FW<br /> error, there is no need to warn, instead - return silently.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf: insert memory barrier before updating num_fences<br /> <br /> smp_store_mb() inserts memory barrier after storing operation.<br /> It is different with what the comment is originally aiming so Null<br /> pointer dereference can be happened if memory update is reordered.