Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix segfault when updating ftrace mask<br /> <br /> Fix invalid data access by passing right data for debugfs entry.<br /> <br /> [ 171.549793] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 171.559248] Mem abort info:<br /> [ 171.562173] ESR = 0x0000000096000044<br /> [ 171.566227] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 171.573108] SET = 0, FnV = 0<br /> [ 171.576448] EA = 0, S1PTW = 0<br /> [ 171.579745] FSC = 0x04: level 0 translation fault<br /> [ 171.584760] Data abort info:<br /> [ 171.588012] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000<br /> [ 171.593734] CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> [ 171.598962] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 171.604471] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000083837000<br /> [ 171.611358] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> [ 171.618500] Internal error: Oops: 0000000096000044 [#1] SMP<br /> [ 171.624222] Modules linked in: powervr drm_shmem_helper drm_gpuvm...<br /> [ 171.656580] CPU: 0 UID: 0 PID: 549 Comm: bash Not tainted 7.0.0-rc2-g730b257ba723-dirty #13 PREEMPT<br /> [ 171.665773] Hardware name: BeagleBoard.org BeaglePlay (DT)<br /> [ 171.671296] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 171.678306] pc : pvr_fw_trace_mask_set+0x78/0x154 [powervr]<br /> [ 171.683959] lr : pvr_fw_trace_mask_set+0x4c/0x154 [powervr]<br /> [ 171.689593] sp : ffff8000835ebb90<br /> [ 171.692929] x29: ffff8000835ebc00 x28: ffff000005c60f80 x27: 0000000000000000<br /> [ 171.700130] x26: 0000000000000000 x25: ffff00000504af28 x24: 0000000000000000<br /> [ 171.707324] x23: ffff00000504af50 x22: 0000000000000203 x21: 0000000000000000<br /> [ 171.714518] x20: ffff000005c44a80 x19: ffff000005c457b8 x18: 0000000000000000<br /> [ 171.721715] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaae8887580<br /> [ 171.728908] x14: 0000000000000000 x13: 0000000000000000 x12: ffff8000835ebc30<br /> [ 171.736095] x11: ffff00000504af2a x10: ffff00008504af29 x9 : 0fffffffffffffff<br /> [ 171.743286] x8 : ffff8000835ebbf8 x7 : 0000000000000000 x6 : 000000000000002a<br /> [ 171.750479] x5 : ffff00000504af2e x4 : 0000000000000000 x3 : 0000000000000010<br /> [ 171.757674] x2 : 0000000000000203 x1 : 0000000000000000 x0 : ffff8000835ebba0<br /> [ 171.764871] Call trace:<br /> [ 171.767342] pvr_fw_trace_mask_set+0x78/0x154 [powervr] (P)<br /> [ 171.772984] simple_attr_write_xsigned.isra.0+0xe0/0x19c<br /> [ 171.778341] simple_attr_write+0x18/0x24<br /> [ 171.782296] debugfs_attr_write+0x50/0x98<br /> [ 171.786341] full_proxy_write+0x6c/0xa8<br /> [ 171.790208] vfs_write+0xd4/0x350<br /> [ 171.793561] ksys_write+0x70/0x108<br /> [ 171.796995] __arm64_sys_write+0x1c/0x28<br /> [ 171.800952] invoke_syscall+0x48/0x10c<br /> [ 171.804740] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 171.809487] do_el0_svc+0x1c/0x28<br /> [ 171.812834] el0_svc+0x34/0x108<br /> [ 171.816013] el0t_64_sync_handler+0xa0/0xe4<br /> [ 171.820237] el0t_64_sync+0x198/0x19c<br /> [ 171.823939] Code: 32000262 b90ac293 1a931056 9134e293 (b9000036)<br /> [ 171.830073] ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/alloc_tag: clear codetag for pages allocated before page_ext initialization<br /> <br /> Due to initialization ordering, page_ext is allocated and initialized<br /> relatively late during boot. Some pages have already been allocated and<br /> freed before page_ext becomes available, leaving their codetag<br /> uninitialized.<br /> <br /> A clear example is in init_section_page_ext(): alloc_page_ext() calls<br /> kmemleak_alloc(). If the slab cache has no free objects, it falls back to<br /> the buddy allocator to allocate memory. However, at this point page_ext<br /> is not yet fully initialized, so these newly allocated pages have no<br /> codetag set. These pages may later be reclaimed by KASAN, which causes<br /> the warning to trigger when they are freed because their codetag ref is<br /> still empty.<br /> <br /> Use a global array to track pages allocated before page_ext is fully<br /> initialized. The array size is fixed at 8192 entries, and will emit a<br /> warning if this limit is exceeded. When page_ext initialization<br /> completes, set their codetag to empty to avoid warnings when they are<br /> freed later.<br /> <br /> This warning is only observed with CONFIG_MEM_ALLOC_PROFILING_DEBUG=Y and<br /> mem_profiling_compressed disabled:<br /> <br /> [ 9.582133] ------------[ cut here ]------------<br /> [ 9.582137] alloc_tag was not set<br /> [ 9.582139] WARNING: ./include/linux/alloc_tag.h:164 at __pgalloc_tag_sub+0x40f/0x550, CPU#5: systemd/1<br /> [ 9.582190] CPU: 5 UID: 0 PID: 1 Comm: systemd Not tainted 7.0.0-rc4 #1 PREEMPT(lazy)<br /> [ 9.582192] Hardware name: Red Hat KVM, BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 9.582194] RIP: 0010:__pgalloc_tag_sub+0x40f/0x550<br /> [ 9.582196] Code: 00 00 4c 29 e5 48 8b 05 1f 88 56 05 48 8d 4c ad 00 48 8d 2c c8 e9 87 fd ff ff 0f 0b 0f 0b e9 f3 fe ff ff 48 8d 3d 61 2f ed 03 48 0f b9 3a e9 b3 fd ff ff 0f 0b eb e4 e8 5e cd 14 02 4c 89 c7<br /> [ 9.582197] RSP: 0018:ffffc9000001f940 EFLAGS: 00010246<br /> [ 9.582200] RAX: dffffc0000000000 RBX: 1ffff92000003f2b RCX: 1ffff110200d806c<br /> [ 9.582201] RDX: ffff8881006c0360 RSI: 0000000000000004 RDI: ffffffff9bc7b460<br /> [ 9.582202] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff3a62324<br /> [ 9.582203] R10: ffffffff9d311923 R11: 0000000000000000 R12: ffffea0004001b00<br /> [ 9.582204] R13: 0000000000002000 R14: ffffea0000000000 R15: ffff8881006c0360<br /> [ 9.582206] FS: 00007ffbbcf2d940(0000) GS:ffff888450479000(0000) knlGS:0000000000000000<br /> [ 9.582208] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9.582210] CR2: 000055ee3aa260d0 CR3: 0000000148b67005 CR4: 0000000000770ef0<br /> [ 9.582211] PKRU: 55555554<br /> [ 9.582212] Call Trace:<br /> [ 9.582213] <br /> [ 9.582214] ? __pfx___pgalloc_tag_sub+0x10/0x10<br /> [ 9.582216] ? check_bytes_and_report+0x68/0x140<br /> [ 9.582219] __free_frozen_pages+0x2e4/0x1150<br /> [ 9.582221] ? __free_slab+0xc2/0x2b0<br /> [ 9.582224] qlist_free_all+0x4c/0xf0<br /> [ 9.582227] kasan_quarantine_reduce+0x15d/0x180<br /> [ 9.582229] __kasan_slab_alloc+0x69/0x90<br /> [ 9.582232] kmem_cache_alloc_noprof+0x14a/0x500<br /> [ 9.582234] do_getname+0x96/0x310<br /> [ 9.582237] do_readlinkat+0x91/0x2f0<br /> [ 9.582239] ? __pfx_do_readlinkat+0x10/0x10<br /> [ 9.582240] ? get_random_bytes_user+0x1df/0x2c0<br /> [ 9.582244] __x64_sys_readlinkat+0x96/0x100<br /> [ 9.582246] do_syscall_64+0xce/0x650<br /> [ 9.582250] ? __x64_sys_getrandom+0x13a/0x1e0<br /> [ 9.582252] ? __pfx___x64_sys_getrandom+0x10/0x10<br /> [ 9.582254] ? do_syscall_64+0x114/0x650<br /> [ 9.582255] ? ksys_read+0xfc/0x1d0<br /> [ 9.582258] ? __pfx_ksys_read+0x10/0x10<br /> [ 9.582260] ? do_syscall_64+0x114/0x650<br /> [ 9.582262] ? do_syscall_64+0x114/0x650<br /> [ 9.582264] ? __pfx_fput_close_sync+0x10/0x10<br /> [ 9.582266] ? file_close_fd_locked+0x178/0x2a0<br /> [ 9.582268] ? __x64_sys_faccessat2+0x96/0x100<br /> [ 9.582269] ? __x64_sys_close+0x7d/0xd0<br /> [ 9.582271] ? do_syscall_64+0x114/0x650<br /> [ 9.582273] ? do_syscall_64+0x114/0x650<br /> [ 9.582275] ? clear_bhb_loop+0x50/0xa0<br /> [ 9.582277] ? clear_bhb_l<br /> ---truncated---