Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix bootup splat with separate_gpu_drm modparam<br /> <br /> The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses<br /> drm_gem_obj.gpuva.list, which is not initialized when the drm driver<br /> does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms<br /> drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam<br /> is set:<br /> <br /> [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0<br /> [ 9.523160] Mem abort info:<br /> [ 9.523161] ESR = 0x0000000096000006<br /> [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 9.523165] SET = 0, FnV = 0<br /> [ 9.523166] EA = 0, S1PTW = 0<br /> [ 9.523167] FSC = 0x06: level 2 translation fault<br /> [ 9.523169] Data abort info:<br /> [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000<br /> [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000<br /> [ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP<br /> [ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT<br /> [ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024<br /> [ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 9.592973] pc : lookup_vma+0x28/0xe0 [msm]<br /> [ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm]<br /> [ 9.763632] sp : ffff800082dab460<br /> [ 9.763666] Call trace:<br /> [ 9.763668] lookup_vma+0x28/0xe0 [msm] (P)<br /> [ 9.763688] get_vma_locked+0x2c/0x128 [msm]<br /> [ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm]<br /> [ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm]<br /> [ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm]<br /> [ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper]<br /> [ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper]<br /> [ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib]<br /> [ 9.763782] drm_client_register+0x58/0x9c [drm]<br /> [ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib]<br /> [ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib]<br /> [ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm]<br /> [ 9.763830] msm_drm_init+0x1a8/0x22c [msm]<br /> [ 9.763848] msm_drm_bind+0x30/0x3c [msm]<br /> [ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4<br /> [ 9.919283] __component_add+0xa4/0x170<br /> [ 9.919286] component_add+0x14/0x20<br /> [ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm]<br /> [ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm]<br /> [ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus]<br /> [ 9.919341] really_probe+0xbc/0x298<br /> [ 9.919345] __driver_probe_device+0x78/0x12c<br /> [ 9.919348] driver_probe_device+0x40/0x160<br /> [ 9.919350] __driver_attach+0x94/0x19c<br /> [ 9.919353] bus_for_each_dev+0x74/0xd4<br /> [ 9.919355] driver_attach+0x24/0x30<br /> [ 9.919358] bus_add_driver+0xe4/0x208<br /> [ 9.919360] driver_register+0x60/0x128<br /> [ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus]<br /> [ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20]<br /> [ 9.919370] do_one_initcall+0x6c/0x1b0<br /> [ 9.919374] do_init_module+0x58/0x234<br /> [ 9.919377] load_module+0x19cc/0x1bd4<br /> [ 9.919380] init_module_from_file+0x84/0xc4<br /> [ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc<br /> [ 9.919384] invoke_syscall+0x48/0x110<br /> [ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8<br /> [ 9.919393] do_el0_svc+0x20/0x2c<br /> [ 9.919396] el0_svc+0x34/0xf0<br /> [ 9.919401] el0t_64_sync_handler+0xa0/0xe4<br /> [ 9.919403] el0t_64_sync+0x198/0x19c<br /> [ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44)<br /> [ 9.919410] ---[ end trace 0000000000000000 ]---<br /> <br /> Patchwork: https://patchwork.freedesktop.org/pa<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: hugetlb: avoid soft lockup when mprotect to large memory area<br /> <br /> When calling mprotect() to a large hugetlb memory area in our customer&amp;#39;s<br /> workload (~300GB hugetlb memory), soft lockup was observed:<br /> <br /> watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]<br /> <br /> CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7<br /> Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mte_clear_page_tags+0x14/0x24<br /> lr : mte_sync_tags+0x1c0/0x240<br /> sp : ffff80003150bb80<br /> x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000<br /> x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458<br /> x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000<br /> x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000<br /> x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000<br /> <br /> Call trace:<br />   mte_clear_page_tags+0x14/0x24<br />   set_huge_pte_at+0x25c/0x280<br />   hugetlb_change_protection+0x220/0x430<br />   change_protection+0x5c/0x8c<br />   mprotect_fixup+0x10c/0x294<br />   do_mprotect_pkey.constprop.0+0x2e0/0x3d4<br />   __arm64_sys_mprotect+0x24/0x44<br />   invoke_syscall+0x50/0x160<br />   el0_svc_common+0x48/0x144<br />   do_el0_svc+0x30/0xe0<br />   el0_svc+0x30/0xf0<br />   el0t_64_sync_handler+0xc4/0x148<br />   el0t_64_sync+0x1a4/0x1a8<br /> <br /> Soft lockup is not triggered with THP or base page because there is<br /> cond_resched() called for each PMD size.<br /> <br /> Although the soft lockup was triggered by MTE, it should be not MTE<br /> specific. The other processing which takes long time in the loop may<br /> trigger soft lockup too.<br /> <br /> So add cond_resched() for hugetlb to avoid soft lockup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping<br /> <br /> When an invalid value is passed via quirk option, currently<br /> bytcr_rt5640 driver only shows an error message but leaves as is.<br /> This may lead to unepxected results like OOB access.<br /> <br /> This patch corrects the input mapping to the certain default value if<br /> an invalid value is passed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: debugfs: Fix legacy mode page table dump logic<br /> <br /> In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR<br /> maybe uninitialized or zero in that case and may cause oops like:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xf00087d3f000f000: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> RIP: 0010:pgtable_walk_level+0x98/0x150<br /> RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206<br /> RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e<br /> RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000<br /> RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002<br /> R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000<br /> R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98<br /> FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> pgtable_walk_level+0x88/0x150<br /> domain_translation_struct_show.isra.0+0x2d9/0x300<br /> dev_domain_translation_struct_show+0x20/0x40<br /> seq_read_iter+0x12d/0x490<br /> ...<br /> <br /> Avoid walking the page table if TT is not 00b or 01b.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()<br /> <br /> The drv-&gt;sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which<br /> would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check<br /> that the pointer is valid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller<br /> <br /> When loading the i10nm_edac driver on some Intel Granite Rapids servers,<br /> a call trace may appear as follows:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16<br /> shift exponent -66 is negative<br /> ...<br /> __ubsan_handle_shift_out_of_bounds+0x1e3/0x390<br /> skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]<br /> i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]<br /> skx_register_mci+0x159/0x220 [skx_edac_common]<br /> i10nm_init+0xcb0/0x1ff0 [i10nm_edac]<br /> ...<br /> <br /> This occurs because some BIOS may disable a memory controller if there<br /> aren&amp;#39;t any memory DIMMs populated on this memory controller. The DIMMMTR<br /> register of this disabled memory controller contains the invalid value<br /> ~0, resulting in the call trace above.<br /> <br /> Fix this call trace by skipping DIMM enumeration on a disabled memory<br /> controller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU in ip6_output()<br /> <br /> Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent<br /> possible UAF.<br /> <br /> We can remove rcu_read_lock()/rcu_read_unlock() pairs<br /> from ip6_finish_output2().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT<br /> <br /> snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts<br /> via spin_lock_irq(). This also implicitly disables the handling of<br /> softirqs such as TIMER_SOFTIRQ.<br /> On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not<br /> disable them. That means a timer can be invoked during spin_lock_irq()<br /> on the same CPU. Due to synchronisations reasons local_bh_disable() has<br /> a per-CPU lock named softirq_ctrl.lock which synchronizes individual<br /> softirq against each other.<br /> syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is<br /> acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This<br /> is a possible deadlock.<br /> <br /> The softirq_ctrl.lock can not be made part of spin_lock_irq() as this<br /> would lead to too much synchronisation against individual threads on the<br /> system. To avoid the possible deadlock, softirqs must be manually<br /> disabled before the lock is acquired.<br /> <br /> Disable softirqs before the lock is acquired on PREEMPT_RT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: dont report verifier bug for missing bpf_scc_visit on speculative path<br /> <br /> Syzbot generated a program that triggers a verifier_bug() call in<br /> maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a<br /> state with insn_idx in some SCC, there should be an instance of struct<br /> bpf_scc_visit allocated for that SCC. Turns out the assumption does<br /> not hold for speculative execution paths. See example in the next<br /> patch.<br /> <br /> maybe_scc_exit() is called from update_branch_counts() for states that<br /> reach branch count of zero, meaning that path exploration for a<br /> particular path is finished. Path exploration can finish in one of<br /> three ways:<br /> a. Verification error is found. In this case, update_branch_counts()<br /> is called only for non-speculative paths.<br /> b. Top level BPF_EXIT is reached. Such instructions are never a part of<br /> an SCC, so compute_scc_callchain() in maybe_scc_exit() will return<br /> false, and maybe_scc_exit() will return early.<br /> c. A checkpoint is reached and matched. Checkpoints are created by<br /> is_state_visited(), which calls maybe_enter_scc(), which allocates<br /> bpf_scc_visit instances for checkpoints within SCCs.<br /> <br /> Hence, for non-speculative symbolic execution paths, the assumption<br /> still holds: if maybe_scc_exit() is called for a state within an SCC,<br /> bpf_scc_visit instance must exist.<br /> <br /> This patch removes the verifier_bug() call for speculative paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure<br /> <br /> When devm_add_action_or_reset() fails, it calls the passed cleanup<br /> function. Hence the caller must not repeat that cleanup.<br /> <br /> Replace the "goto err_regulator_free" by the actual freeing, as there<br /> will never be a need again for a second user of this label.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix potential deadlock while nr_requests grown<br /> <br /> Allocate and free sched_tags while queue is freezed can deadlock[1],<br /> this is a long term problem, hence allocate memory before freezing<br /> queue and free memory after queue is unfreezed.<br /> <br /> [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-throttle: fix access race during throttle policy activation<br /> <br /> On repeated cold boots we occasionally hit a NULL pointer crash in<br /> blk_should_throtl() when throttling is consulted before the throttle<br /> policy is fully enabled for the queue. Checking only q-&gt;td != NULL is<br /> insufficient during early initialization, so blkg_to_pd() for the<br /> throttle policy can still return NULL and blkg_to_tg() becomes NULL,<br /> which later gets dereferenced.<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> at virtual address 0000000000000156<br /> ...<br /> pc : submit_bio_noacct+0x14c/0x4c8<br /> lr : submit_bio_noacct+0x48/0x4c8<br /> sp : ffff800087f0b690<br /> x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0<br /> x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70<br /> x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000<br /> x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff<br /> x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff<br /> x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c<br /> x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60<br /> x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002<br /> x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500<br /> x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a<br /> Call trace:<br /> submit_bio_noacct+0x14c/0x4c8<br /> verity_map+0x178/0x2c8<br /> __map_bio+0x228/0x250<br /> dm_submit_bio+0x1c4/0x678<br /> __submit_bio+0x170/0x230<br /> submit_bio_noacct_nocheck+0x16c/0x388<br /> submit_bio_noacct+0x16c/0x4c8<br /> submit_bio+0xb4/0x210<br /> f2fs_submit_read_bio+0x4c/0xf0<br /> f2fs_mpage_readpages+0x3b0/0x5f0<br /> f2fs_readahead+0x90/0xe8<br /> <br /> Tighten blk_throtl_activated() to also require that the throttle policy<br /> bit is set on the queue:<br /> <br /> return q-&gt;td != NULL &amp;&amp;<br /> test_bit(blkcg_policy_throtl.plid, q-&gt;blkcg_pols);<br /> <br /> This prevents blk_should_throtl() from accessing throttle group state<br /> until policy data has been attached to blkgs.