CVE-2025-71143HighMicrosoft CVSS 7.1CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Microsoft advisory for CVE-2025-71143 — azl3 kernel 6.6.119.3-1 on Azure Linux 3.0

Published
June 2, 2026
Last Modified
—

🔗 CVE IDs covered (1)

📋 Microsoft's advisory

EchelonGraph does not copy Microsoft's advisory page: its FAQ and remediation text are not shown here. Read the advisory on https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-71143. This page also shows what EchelonGraph holds for CVE-2025-71143, with the description from its CVE record, which the CVE Numbering Authority that assigned the CVE wrote: for a CVE Microsoft assigned, often in the words of Microsoft's own advisory.

🎯 Affected products1

  • azl3 kernel 6.6.119.3-1 on Azure Linux 3.0

🧭 EchelonGraph on CVE-2025-71143

EchelonGraph score
7.8 HIGH
CISA KEV
Not listed
Fix status
A fix is available — apply it.

Description from the CVE record (CVE.org), as published by its numbering authority

In the Linux kernel, the following vulnerability has been resolved: clk: samsung: exynos-clkout: Assign .num before accessing .hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in exynos_clkout_probe() due to .num being assigned after .hws[] has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]' Move the .num initialization to before the first access of .hws[], clearing up the warning.

Published by kernel.org, the CVE Numbering Authority that assigned CVE-2025-71143, in its CVE record at CVE.org; reused under the CVE Program's Terms of Use (its licence and MITRE's copyright notice are in our Terms of Service).

🔗 References (1)