Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Disable broadcast TLB flush when PCID is disabled<br /> <br /> Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being<br /> set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains<br /> enabled.<br /> <br /> There are two checks that decide whether the global ASID code runs,<br /> mm_global_asid() and consider_global_asid(), that key off of the<br /> X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three<br /> CPUs, consider_global_asid() assigns it a global ASID, after which<br /> flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero<br /> PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set<br /> results in a #GP:<br /> <br /> Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI<br /> CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)<br /> Hardware name: ...<br /> RIP: 0010:broadcast_tlb_flush<br /> Code: ... 89 da 48 83 c8 07 01 fe eb 08 cc cc cc ...<br /> Call Trace:<br /> <br /> flush_tlb_mm_range<br /> ptep_clear_flush<br /> wp_page_copy<br /> ? _raw_spin_unlock<br /> __handle_mm_fault<br /> handle_mm_fault<br /> do_user_addr_fault<br /> exc_page_fault<br /> asm_exc_page_fault<br /> <br /> All processors that support broadcast TLB invalidation also have PCID support,<br /> so it is only the "nopcid" scenario that is of concern. In this situation just<br /> disable the broadcast TLB support using the CPUID dependency support by making<br /> X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.<br /> <br /> [ bp: Massage commit message. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: tps65219: fix irq_data.rdev not being assigned<br /> <br /> Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper<br /> function") removed the tps65219_get_rdev_by_name() helper along with<br /> the irq_data.rdev assignment that depended on it. This left<br /> irq_data.rdev uninitialized for all IRQs, causing undefined behavior<br /> when regulator_notifier_call_chain() is called from the IRQ handler:<br /> <br /> Internal error: Oops: 0000000096000004<br /> pc : regulator_notifier_call_chain<br /> lr : tps65219_regulator_irq_handler<br /> Call trace:<br /> regulator_notifier_call_chain<br /> tps65219_regulator_irq_handler<br /> handle_nested_irq<br /> regmap_irq_thread<br /> irq_thread_fn<br /> irq_thread<br /> kthread<br /> ret_from_fork<br /> <br /> Instead of restoring a dedicated lookup array, restructure the probe<br /> function to combine regulator registration with IRQ registration in<br /> the same loop. This way the rdev returned by devm_regulator_register()<br /> is naturally available for assigning to irq_data.rdev without any<br /> auxiliary data structure.<br /> <br /> Non-regulator IRQs (SENSOR, TIMEOUT) that don&amp;#39;t correspond to any<br /> registered regulator are registered with rdev=NULL, and the IRQ handler<br /> is protected with a NULL check to avoid crashing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: don&amp;#39;t dump registers past the mapped region<br /> <br /> On DSI 6G platforms the IO address space is internally adjusted by<br /> io_offset. Later this adjusted address might be used for memory dumping.<br /> However the size that is used for memory dumping isn&amp;#39;t adjusted to<br /> account for the io_offset, leading to the potential access to the<br /> unmapped region. Lower ctrl_size by the io_offset value to prevent<br /> access past the mapped area.<br /> <br /> msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P)<br /> msm_dsi_host_snapshot+0x4c/0x78 [msm]<br /> msm_dsi_snapshot+0x28/0x50 [msm]<br /> msm_disp_snapshot_capture_state+0x74/0x140 [msm]<br /> msm_disp_snapshot_state_sync+0x60/0x90 [msm]<br /> _msm_disp_snapshot_work+0x30/0x90 [msm]<br /> kthread_worker_fn+0xdc/0x460<br /> kthread+0x120/0x140<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/721747/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: hold opts-&gt;lock across XU walks in uvc_function_bind<br /> <br /> uvc_function_bind() walks &amp;opts-&gt;extension_units twice without holding<br /> opts-&gt;lock:<br /> <br /> - directly, for the iExtension string-descriptor fixup loop;<br /> - indirectly, four times via uvc_copy_descriptors() (once per speed),<br /> where the helper iterates uvc-&gt;desc.extension_units (which aliases<br /> &amp;opts-&gt;extension_units) to size and emit XU descriptors.<br /> <br /> The configfs side (uvcg_extension_make / uvcg_extension_drop, in<br /> drivers/usb/gadget/function/uvc_configfs.c) takes opts-&gt;lock around its<br /> list_add_tail / list_del operations. A privileged userspace process<br /> that holds the configfs subtree open and writes the gadget UDC name<br /> to bind the function while concurrently rmdir()&amp;#39;ing an extensions<br /> subdir can race uvcg_extension_drop() against the bind-time list walks<br /> and dereference a freed struct uvcg_extension.<br /> <br /> Hold opts-&gt;lock from the start of the XU string-descriptor fixup<br /> through the last uvc_copy_descriptors() call, releasing on the<br /> descriptor-error path via a new error_unlock label that drops the<br /> lock before falling through to the existing error label. This<br /> matches the locking discipline of the configfs callbacks and removes<br /> the only remaining unsynchronised reader of the XU list during bind.<br /> <br /> Reachability: only privileged processes that can mount configfs and<br /> write to gadget UDC files can trigger the race, so this is a<br /> correctness fix rather than a security boundary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: pch_uart: add check for dma_alloc_coherent()<br /> <br /> Add a check for dma_alloc_coherent() failure to prevent a potential<br /> NULL pointer dereference in dma_handle_rx(). Properly release DMA<br /> channels and the PCI device reference using a goto ladder if the<br /> allocation fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: davinci: fix division by zero on missing clock-frequency<br /> <br /> When the &amp;#39;clock-frequency&amp;#39; property is missing from the device tree,<br /> the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this<br /> macro was defined in kHz (100), whereas the device tree property is<br /> expected in Hz.<br /> <br /> The probe function divided the fallback value by 1000, causing<br /> integer truncation that resulted in dev-&gt;bus_freq = 0. This triggered<br /> a deterministic division-by-zero kernel panic when calculating clock<br /> dividers later in the probe sequence.<br /> <br /> Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)<br /> to match the expected device tree property unit, allowing the existing<br /> division logic to work correctly for both cases.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: recompute nr_integrity_segments in blk_insert_cloned_request<br /> <br /> blk_insert_cloned_request() already recomputes nr_phys_segments<br /> against the bottom queue, because "the queue settings related to<br /> segment counting may differ from the original queue." The exact same<br /> reasoning applies to integrity segments: a stacked driver&amp;#39;s underlying<br /> queue can have tighter virt_boundary_mask, seg_boundary_mask, or<br /> max_segment_size than the top queue, in which case<br /> blk_rq_count_integrity_sg() against the bottom queue produces a<br /> different count than the cached rq-&gt;nr_integrity_segments inherited<br /> from the source request by blk_rq_prep_clone().<br /> <br /> When the cached count is lower than the bottom queue&amp;#39;s actual count,<br /> blk_rq_map_integrity_sg() trips<br /> <br /> BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);<br /> <br /> on dispatch. The same families of stacked setups that motivated the<br /> existing nr_phys_segments recompute -- dm-multipath fanning out to<br /> nvme-rdma in particular -- can produce this.<br /> <br /> Mirror the nr_phys_segments handling: when the request carries<br /> integrity, recompute nr_integrity_segments against the bottom queue<br /> and reject the request if it exceeds the bottom queue&amp;#39;s<br /> max_integrity_segments. blk_rq_count_integrity_sg() and<br /> queue_max_integrity_segments() are both already available via<br /> , which blk-mq.c includes.<br /> <br /> This closes a latent gap in the stacking contract and brings the<br /> integrity-segment accounting in line with the existing<br /> phys-segment accounting.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines<br /> <br /> With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform<br /> (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline<br /> crashes on the first call into the traced function:<br /> <br /> BUG: unable to handle page fault for address: ffff88817ae18880<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 4b53067 P4D 4b53067 PUD 0<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014<br /> Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89<br /> Call Trace:<br /> <br /> ? find_held_lock<br /> ? exc_page_fault<br /> ? lock_release<br /> ? __x64_sys_clock_nanosleep<br /> ? lockdep_hardirqs_on_prepare<br /> ? trace_hardirqs_on<br /> __x64_sys_clock_nanosleep<br /> do_syscall_64<br /> ? exc_page_fault<br /> ? call_depth_return_thunk<br /> entry_SYSCALL_64_after_hwframe<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> This small reproducer allows to easily trigger the crash:<br /> <br /> # echo &amp;#39;p __x64_sys_clock_nanosleep&amp;#39; &gt; /sys/kernel/tracing/kprobe_events<br /> # echo 1 &gt; /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable<br /> # usleep 1<br /> <br /> Monitoring the crash under GDB points to the exact instruction in charge of<br /> incrementing the call depth:<br /> <br /> sarq $5, %gs:__x86_call_depth(%rip)<br /> <br /> This instruction matches the one inserted by the ftrace_regs_caller from<br /> ftrace_64.S. This emitted code was likely working fine until the introduction<br /> of<br /> <br /> 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"):<br /> <br /> it has made the call depth accounting addressing relative to $rip, instead of<br /> being based on an absolute address.<br /> <br /> As this code exact location depends on where the trampoline lives in memory,<br /> the corresponding displacement needs to be adjusted at runtime to actually<br /> correctly find the per-cpu __x86_call_depth value, otherwise the targeted<br /> address is wrong, leading to the page fault seen above.<br /> <br /> Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT<br /> instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(),<br /> as it is done for example by the x86 BPF JIT compiler through<br /> x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots,<br /> in ftrace_caller and ftrace_regs_caller.<br /> <br /> [ bp: Massage. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: elan_i2c - validate firmware size before use<br /> <br /> Ensure that the firmware file is large enough to contain the expected<br /> number of pages and the signature (which resides at the end of the<br /> firmware blob) before accessing them to prevent potential out-of-bounds<br /> reads.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: fix double free in rvu_rep_rsrc_init()<br /> <br /> rvu_rep_rsrc_init() allocates queue memory before calling<br /> otx2_init_hw_resources(). When hardware resource setup fails,<br /> otx2_init_hw_resources() already unwinds the partially initialized<br /> SQ, CQ, and aura state before returning an error. The representor<br /> error path then calls otx2_free_hw_resources() again and can free<br /> the same resources a second time.<br /> <br /> Fix this by splitting the cleanup labels so that a failure from<br /> otx2_init_hw_resources() only releases queue memory. Keep the<br /> otx2_free_hw_resources() call for failures that happen after<br /> hardware resource initialization completed successfully.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1-rc3.<br /> <br /> Runtime validation was not performed because reproducing this path<br /> requires OcteonTX2 representor hardware.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: CGX: add bounds check to cgx_speed_mbps index<br /> <br /> cgx_speed_mbps has 13 elements but RESP_LINKSTAT_SPEED can yield values<br /> 0-15. If it returns a value &gt;= 13, this causes an out-of-bounds array<br /> access. Add a bounds check and default to speed 0 if the index is out of<br /> range.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: phy: avoid NULL deref when PHY driver is unbound<br /> <br /> phydev-&gt;drv can become NULL while the phy_device is still attached to<br /> its net_device, namely after the PHY driver is unbound via sysfs:<br /> <br /> echo &gt; /sys/bus/mdio_bus/drivers//unbind<br /> <br /> phy_remove() clears phydev-&gt;drv but doesn&amp;#39;t call phy_detach(), so the<br /> phy_device stays in the link topology xarray and ethnl_req_get_phydev()<br /> still hands it back. ETHTOOL_MSG_PHY_GET then oopses on:<br /> <br /> rep_data-&gt;drvname = kstrdup(phydev-&gt;drv-&gt;name, GFP_KERNEL);<br /> <br /> drvname is already treated as optional by phy_reply_size(),<br /> phy_fill_reply() and phy_cleanup_data(), so just skip the allocation<br /> when there is no driver bound.