Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path<br /> <br /> In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error()<br /> dereferences p-&gt;comm and p-&gt;pid. If the iterator&amp;#39;s reference is the last<br /> drop, the task is freed synchronously and the deref becomes a UAF.<br /> <br /> Move put_task_struct() past scx_error().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: driver: Check ACPI_COMPANION() against NULL during probe<br /> <br /> Since every platform driver can be forced to match a device that doesn&amp;#39;t<br /> match its list of device IDs because of device_match_driver_override(),<br /> platform drivers that rely on the existence of a device&amp;#39;s ACPI companion<br /> object should verify its presence.<br /> <br /> Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks<br /> against NULL to 13 platform drivers handling core ACPI devices.<br /> <br /> Also change the value returned by the ACPI thermal zone driver when<br /> the device&amp;#39;s ACPI companion is not present to -ENODEV for consistency<br /> with the other drivers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: avoid double free of pool-&gt;stack on AQ init failure<br /> <br /> otx2_pool_aq_init() frees pool-&gt;stack when mailbox sync or retry<br /> allocation fails, but leaves the pointer unchanged. Later,<br /> otx2_sq_aura_pool_init() unwinds the partial setup through<br /> otx2_aura_pool_free(), which frees pool-&gt;stack again. The CN20K-specific<br /> cn20k_pool_aq_init() implementation has the same bug in<br /> its corresponding error path.<br /> <br /> Set pool-&gt;stack to NULL immediately after the local free so the shared<br /> cleanup path does not free the same stack again while cleaning up<br /> partially initialized pool state.<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 present in<br /> v7.1-rc3.<br /> <br /> Runtime validation was not performed because reproducing this path<br /> requires OcteonTX2/CN20K hardware.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: consume only present negotiated TTLM maps<br /> <br /> ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements<br /> against the number of link-map entries indicated by link_map_presence.<br /> ieee80211_parse_neg_ttlm() must consume the same layout.<br /> <br /> The parser advanced its cursor for every TID, including TIDs whose<br /> presence bit is clear and therefore have no map bytes in the element.<br /> A sparse map can then make a later present TID read past the validated<br /> element.<br /> <br /> The bad bytes land in neg_ttlm-&gt;{up,down}link[tid] but are gated by<br /> valid_links before being applied to driver state, so a peer cannot<br /> turn the read into a policy change. Under KUnit + KASAN with an<br /> exact-sized element allocation the OOB read is reported as a<br /> slab-out-of-bounds; whether the same trigger fires under the<br /> production RX path depends on surrounding allocator state.<br /> <br /> Advance the cursor only when the current TID has a map present.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()<br /> <br /> A kernel panic is observed when handling machine check exceptions from<br /> real mode.<br /> <br /> BUG: Unable to handle kernel data access on read at 0xc00000006be21300<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> MSR: 8000000000001003 CR: 88222248 XER: 00000005<br /> CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0<br /> NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70<br /> LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150<br /> Call Trace:<br /> [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150<br /> [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0<br /> <br /> The crash occurs because arch_irq_work_raise() calls preempt_disable()<br /> from machine check exception (MCE) handlers running in real mode. In<br /> this context, accessing the preempt_count can fault, leading to the panic.<br /> <br /> The preempt_disable()/preempt_enable() pair in arch_irq_work_raise()<br /> was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix<br /> oops due to perf_event_do_pending call") to avoid races while raising<br /> irq work from exception context.<br /> <br /> Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when<br /> queueing work on the local CPU") added preemption protection in<br /> irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per<br /> cpu atomics instead of regular atomics") added equivalent<br /> protection in irq_work_queue_on() before reaching arch_irq_work_raise():<br /> <br /> irq_work_queue() / irq_work_queue_on()<br /> -&gt; preempt_disable()<br /> -&gt; __irq_work_queue_local()<br /> -&gt; irq_work_raise()<br /> -&gt; arch_irq_work_raise()<br /> <br /> As a result, callers other than mce_irq_work_raise() already execute<br /> with preemption disabled, making the additional<br /> preempt_disable()/preempt_enable() pair in arch_irq_work_raise()<br /> redundant.<br /> <br /> The arch_irq_work_raise() function executes in NMI context when called<br /> from MCE handler. Hence we will not be preempted or scheduled out since<br /> we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove<br /> the preempt_disable()/preempt_enable() calls from here.<br /> <br /> Remove it to avoid accessing preempt_count from real mode context.<br /> <br /> [Maddy: Fixed the commit title]