Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - guard HMAC key hex dumps in hash_digest_key<br /> <br /> Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in<br /> hash_digest_key() to avoid leaking secrets at runtime when<br /> CONFIG_DYNAMIC_DEBUG is enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/scatterlist: fix length calculations in extract_kvec_to_sg<br /> <br /> Patch series "Fix bugs in extract_iter_to_sg()", v3.<br /> <br /> Fix bugs in the kvec and user variants of extract_iter_to_sg. This series<br /> is growing due to useful remarks made by sashiko.dev.<br /> <br /> The main bugs are:<br /> - The length for an sglist entry when extracting from<br /> a kvec can exceed the number of bytes in the page. This<br /> is obviously not intended.<br /> - When extracting a user buffer the sglist is temporarily<br /> used as a scratch buffer for extracted page pointers.<br /> If the sglist already contains some elements this scratch<br /> buffer could overlap with existing entries in the sglist.<br /> <br /> The series adds test cases to the kunit_iov_iter test that demonstrate all<br /> of these bugs. Additionally, there is a memory leak fix for the test<br /> itself.<br /> <br /> The bugs were orignally introduced into kernel v6.3 where the function<br /> lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in<br /> v6.5. Thus the actual fix is only marked for backports to v6.5+.<br /> <br /> <br /> This patch (of 5):<br /> <br /> When extracting from a kvec to a scatterlist, do not cross page<br /> boundaries. The required length was already calculated but not used as<br /> intended.<br /> <br /> Adjust the copied length if the loop runs out of sglist entries without<br /> extracting everything.<br /> <br /> While there, return immediately from extract_iter_to_sg if there are no<br /> sglist entries at all.<br /> <br /> A subsequent commit will add kunit test cases that demonstrate that the<br /> patch is necessary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efi: Fix graceful fault handling after FPU softirq changes<br /> <br /> Since commit d02198550423 ("x86/fpu: Improve crypto performance by<br /> making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()<br /> calls fpregs_lock() which uses local_bh_disable() instead of the<br /> previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count<br /> during the entire EFI runtime service call, causing in_interrupt() to<br /> return true in normal task context.<br /> <br /> The graceful page fault handler efi_crash_gracefully_on_page_fault()<br /> uses in_interrupt() to bail out for faults in real interrupt context.<br /> With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI<br /> firmware page faults unhandled. This escalates to die() which also sees<br /> in_interrupt() as true and calls panic("Fatal exception in interrupt"),<br /> resulting in a hard system freeze. On systems with buggy firmware that<br /> triggers page faults during EFI runtime calls (e.g., accessing unmapped<br /> memory in GetTime()), this causes an unrecoverable hang instead of the<br /> expected graceful EFI_ABORTED recovery.<br /> <br /> Fix by replacing in_interrupt() with !in_task(). This preserves the<br /> original intent of bailing for interrupts or NMI faults, while no longer<br /> falsely triggering from the FPU code path&amp;#39;s local_bh_disable().<br /> <br /> [ardb: Sashiko spotted that using &amp;#39;in_hardirq() || in_nmi()&amp;#39; leaves a<br /> window where a softirq may be taken before fpregs_lock() is<br /> called, but after efi_rts_work.efi_rts_id has been assigned,<br /> and any page faults occurring in that window will then be<br /> misidentified as having been caused by the firmware. Instead,<br /> use !in_task(), which incorporates in_serving_softirq(). ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: microchip: mpfs-ccc: fix out of bounds access during output registration<br /> <br /> UBSAN reported an out of bounds access during registration of the last<br /> two outputs. This out of bounds access occurs because space is only<br /> allocated in the hws array for two PLLs and the four output dividers<br /> that each has, but the defined IDs contain two DLLS and their two<br /> outputs each, which are not supported by the driver. The ID order is<br /> PLLs -&gt; DLLs -&gt; PLL outputs -&gt; DLL outputs. Decrement the PLL output IDs<br /> by two while adding them to the array to avoid the problem.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix early boot crash on parameters without &amp;#39;=&amp;#39; separator<br /> <br /> If hugepages, hugepagesz, or default_hugepagesz are specified on the<br /> kernel command line without the &amp;#39;=&amp;#39; separator, early parameter parsing<br /> passes NULL to hugetlb_add_param(), which dereferences it in strlen() and<br /> can crash the system during early boot.<br /> <br /> Reject NULL values in hugetlb_add_param() and return -EINVAL instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: docg3: fix use-after-free in docg3_release()<br /> <br /> In docg3_release(), the docg3 pointer is obtained from<br /> cascade-&gt;floors[0]-&gt;priv before the loop that calls<br /> doc_release_device() on each floor. doc_release_device() frees the<br /> docg3 struct via kfree(docg3) at line 1881. After the loop,<br /> docg3-&gt;cascade-&gt;bch dereferences the already-freed pointer.<br /> <br /> Fix this by accessing cascade-&gt;bch directly, which is equivalent<br /> since docg3-&gt;cascade points back to the same cascade struct, and<br /> is already available as a local variable. This also removes the<br /> now-unused docg3 local variable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Use kfree_sensitive() to free auth session in tpm_dev_release()<br /> <br /> tpm_dev_release() uses plain kfree() to free chip-&gt;auth, which contains<br /> sensitive cryptographic material including HMAC session keys, nonces,<br /> and passphrase data (struct tpm2_auth).<br /> <br /> Every other code path that frees this structure uses kfree_sensitive()<br /> to zero the memory before releasing it: both tpm2_end_auth_session()<br /> and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path<br /> is the only one that does not, leaving key material in freed slab<br /> memory until it is eventually overwritten.<br /> <br /> Use kfree_sensitive() for consistency with the rest of the driver and<br /> to ensure session keys are scrubbed during device teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: qcom-lpg: Check for array overflow when selecting the high resolution<br /> <br /> When selecting the high resolution values from the array, FIELD_GET() is<br /> used to pull from a 3 bit register, yet the array being indexed has only<br /> 5 values in it. Odds are the hardware is sane, but just to be safe,<br /> properly check before just overflowing and reading random data and then<br /> setting up chip values based on that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: fix RTNL assertion warning when remove module<br /> <br /> For the copper NIC with external PHY, the driver called<br /> phylink_connect_phy() during probe and phylink_disconnect_phy() during<br /> remove. It caused an RTNL assertion warning in phylink_disconnect_phy()<br /> upon module remove.<br /> <br /> To fix this, add rtnl_lock() and rtnl_unlock() around the<br /> phylink_disconnect_phy() in remove function.<br /> <br /> ------------[ cut here ]------------<br /> RTNL: assertion failed at drivers/net/phy/phylink.c (2351)<br /> WARNING: drivers/net/phy/phylink.c:2351 at<br /> phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464<br /> Modules linked in: ...<br /> CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+<br /> Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING<br /> PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024<br /> RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]<br /> Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7<br /> 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 48 0f b9 3a<br /> e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000<br /> RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020<br /> RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000<br /> R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348<br /> FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> txgbe_remove_phy+0xbb/0xd0 [txgbe]<br /> txgbe_remove+0x4c/0xb0 [txgbe]<br /> pci_device_remove+0x41/0xb0<br /> device_remove+0x43/0x80<br /> device_release_driver_internal+0x206/0x270<br /> driver_detach+0x4a/0xa0<br /> bus_remove_driver+0x83/0x120<br /> driver_unregister+0x2f/0x60<br /> pci_unregister_driver+0x40/0x90<br /> txgbe_driver_exit+0x10/0x850 [txgbe]<br /> __do_sys_delete_module.isra.0+0x1c3/0x2f0<br /> __x64_sys_delete_module+0x12/0x20<br /> x64_sys_call+0x20c3/0x2390<br /> do_syscall_64+0x11c/0x1500<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_syscall_64+0x15a/0x1500<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_fault+0x312/0x580<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __handle_mm_fault+0x9d5/0x1040<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? count_memcg_events+0x101/0x1d0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? handle_mm_fault+0x1e8/0x2f0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_user_addr_fault+0x2f8/0x820<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? irqentry_exit+0xb2/0x600<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? exc_page_fault+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: fix use-after-free in of_unittest_changeset()<br /> <br /> The variable &amp;#39;parent&amp;#39; is assigned the value of &amp;#39;nchangeset&amp;#39; earlier in the<br /> function, meaning both point to the same struct device_node. The call to<br /> of_node_put(nchangeset) can decrement the reference count to zero and<br /> free the node if there are no other holders. After that, the code still<br /> uses &amp;#39;parent&amp;#39; to check for the presence of a property and to read a<br /> string property, leading to a use-after-free.<br /> <br /> Fix this by moving the of_node_put() call after the last access to<br /> &amp;#39;parent&amp;#39;, avoiding the UAF.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix zero-size GDS range init on RDNA4<br /> <br /> RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory<br /> resources. The gfx_v12_0 initialisation code correctly leaves<br /> adev-&gt;gds.gds_size, adev-&gt;gds.gws_size, and adev-&gt;gds.oa_size at<br /> zero to reflect this.<br /> <br /> amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for<br /> each of these resources regardless of size. When the size is zero,<br /> amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(),<br /> which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires<br /> DRM_MM_BUG_ON(start + size

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/zone_device: do not touch device folio after calling -&gt;folio_free()<br /> <br /> The contents of a device folio can immediately change after calling<br /> -&gt;folio_free(), as the folio may be reallocated by a driver with a<br /> different order. Instead of touching the folio again to extract the<br /> pgmap, use the local stack variable when calling percpu_ref_put_many().